On Mon, 9 Mar 2015, Tony Lindgren wrote: > > > > > Considering the above, should we add a new function something like > > > > > pm_resume_complete() that does not need irq_safe set but does > > > > > not return until the device has completed resume? > > > > > > > > That doesn't make sense. You're asking for a routine that is allowed > > > > to sleep but can safely be called in interrupt context. > > > > > > Oh it naturally would not work in irq context, it's for the bottom > > > half again. > > > > In other words, you're suggesting we add a function that runs in > > process context and doesn't return until the device is fully resumed? > > That's exactly what pm_runtime_resume does right now. > > But doesn't it only wait for completion if the driver is marked with > pm_runtime_irq_safe()? Put it this way: pm_runtime_resume invokes a ->runtime_resume callback routine (the subsystem's or the driver's or whichever), and it assumes that if the routine returns 0 then the device has been resumed. It doesn't really _wait_ for anything; it just calls the callback routine. It behaves this way whether or not the irq_safe flag is set. The only difference is that if irq_safe is set then the callback routine is invoked with interrupts disabled (and in this case pm_runtime_resume may be called in interrupt context -- normally it can be called only in process context). 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
