Alen,
On Saturday 27 August 2011 12:06 AM, Alan Stern wrote:
On Fri, 26 Aug 2011, Govindraj.R wrote:
Hello,
During system_wide_suspend pm runtime is disabled.
I.e. __pm_runtime_disable is called from __device_suspend.
Now, if a wakeup interrupt is triggered and the wakeup device irq handler
is called even before device_resume and pm_runtime_enable happens,
the device irq_handler proceeds to enable clock with runtime API to
handle wakeup event.
Wouldn't this result in system wide abort since the pm_runtime is not enabled
yet from dpm_resume?
As we end up accessing regs after doing runtime get_sync.
Looks like this scenario is not handled currently.
Or Am I missing something here?
I don't have the complete picture, but it seems that the IRQ handler
needs to check the return code from pm_runtime_get_sync(). If the call
fails then the handler shouldn't try to access the device registers.
In the case of a genuine wakeup event, the event should be handled
later on as part of the resume or resume_noirq processing.
However, this does raise a potential problem. What happens if the
clocks are needed in order to turn off the IRQ source? Runtime PM
won't allow the clocks to be enabled until after interrupts have been
enabled, and by then it will be too late -- the source will have caused
an interrupt storm.
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.
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
