[lkml]   [2009]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] PM: Introduce core framework for run-time PM of I/O devices (rev. 3)
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.


 \ /
  Last update: 2009-06-24 02:11    [W:0.073 / U:8.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site