* Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> [150309 08:42]: > 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). Oh right you are. Looking at rpm_resume() again, it's the RPM_ASYNC that was causing problems to me earlier, not the irq_safe. Sorry it seems I was a bit confused. And yes, pm_runtime_resume() does not set RPM_ASYNC like you pointed out earlier so no need to do anything there. Regards, Tony -- 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
