On Tuesday 23 June 2009, Alan Stern wrote: > On Tue, 23 Jun 2009, Rafael J. Wysocki wrote: > > > Hi, > > > > Below is a new revision of the patch introducing the run-time PM framework. > > > > The most visible changes from the last version: > > > > * I realized that if child_count is atomic, we can drop the parent locking from > > all of the functions, so I did that. > > > > * Introduced pm_runtime_put() that decrements the resume counter and queues > > up an idle notification if the counter went down to 0 (and wasn't 0 previously). > > Using asynchronous notification makes it possible to call pm_runtime_put() > > from interrupt context, if necessary. > > > > * Changed the meaning of the RPM_WAKE bit slightly (it is now also used for > > disabling run-time PM for a device along with the resume counter). > > > > Please let me know if I've overlooked anything. :-) > > This first thing to strike me was that you moved the idle notifications > into the workqueue. Yes, I did. > Is that really needed? Would we be better off just make the idle > callbacks directly from pm_runtime_put? They would run in whatever > context the driver happened to be in at the time. > > It's not clear exactly how much work the idle callbacks will need to > do, but it seems likely that they won't have to do too much more than > call pm_request_suspend. And of course, that can be done in_interrupt. I just don't want to put any constraints on the implementation of ->runtime_idle(). The requirement that it be suitable for calling from interrupt context may be quite inconvenient for some drivers and I'm afraid they may have problems with meeting it. Best, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
