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. Alan Stern -- 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
