On Thu, 23 Sep 2010, Kevin Hilman wrote: > Hello, > > Looking for advice for a little runtime PM dilemma... > > After some inactivity, a driver decides to supend iteslf using > pm_runtime_put_sync(). > > The device is now suspended, it's ->runtime_suspend() method has > disabled its clock, so its registers cannot be accessed anymore. > > Now, as interrupts are still enabled, an interrupt for this device might > still arrive. For example, if this device is a wakeup source, its > ->runtime_suspend() method may not have masked its interrupt. Right. > So, the IRQ fires, and the drivers ISR is called. The driver wants to > access the device registers, but since it has been runtime suspended, > it's registers are not available. > > The first reflex would be to simply do a pm_runtime_get_sync() in the > ISR, however this is not safe if the ISR is an IRQs-disabled handler (as > is the case for me, where the problematic handler is chained handler > used for demuxing GPIO IRQs.) An ISR shouldn't call pm_runtime_get_sync() in any case. > So, what is the "right" thing to do here? You should call pm_runtime_get(), turn off the interrupt source, and return. Then your resume routine should check for an outstanding interrupt or wakeup request and handle it (the easiest way may be simply to call the ISR). > A quick hack would be to for the drivers ISR to do a > pm_runtime_get_noresume() and directly call the its ->runtime_resume() > method, then do its normal stuff, followed by a pm_runtime_put() at the > end of the ISR. > > Is this an acceptable hack given that it's only needed for the > increasingly rare cases of ISRs with interrupts disabled? > > Or should we think of making a version of _get_sync() that is safe for > IRQs disabled contexts like this where we know the device is already > RPM_SUSPENDED? > > Any advice appreciated... You're trying to fight the runtime-PM design instead of using it as it was intended. We already have an API for starting a resume from interrupt context, and that's what you should use. 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
