On Saturday 27 August 2011 07:31 PM, Alan Stern wrote:
On Sat, 27 Aug 2011, Santosh wrote:
I might be wrong here, but after discussion with Govindraj on this
issue, it seems there is a flaw in the way OMAP chain handler
handling the child interrupts.
On OMAP, we have special interrupt wakeup source at PRCM level and
many devices can trigger wakeup from low power via this common
interrupt source. The common interrupt source upon wakeup from low
power state, decodes the source of interrupt and based on that
source, calls the respective device ISR directly.
The issue I see here is, the ISR on _a_ device (UART in this case)
is happening even before UART resume and DPM resume has been completed.
If this is the case, then it is surely asking for trouble. Because not
just clocks, but even driver state machine is already in suspend state
when the ISR is called.
If the driver state machine is in the suspend state when the ISR is
called, then the ISR should realize it is handling a wakeup event
instead of a normal I/O event. All it needs to do is turn off the
interrupt source; the event itself will be taken care of during the
device's resume callback.
Good point but the ISR is called as a function call and not real
hardware event so no need to turn-off the source in the child
ISR. Parent ISR will clear the source anyways.
But the intention here is to record the event for the child.
I mean for UART wakeup, the received character should be
extracted. If not done, UART will loose that character because
the event is lost. So not sure how the event will be taken
care during resume callback. Could you elaborate bit more on
last comment please?
Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
