[lkml]   [2009]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 6)
On Mon, 29 Jun 2009, Rafael J. Wysocki wrote:

> > It doesn't need to know. All it needs to do is guarantee that the
> > device will be in a resumed state some time not long after the function
> > returns. Thus calling rpm_request_resume while the status is RPM_IDLE
> > is like calling it while the status is RPM_ACTIVE. In neither case
> > does it have to do anything, because the device will already be resumed
> > when it returns.
> Not exactly, because RPM_IDLE prevents idle notifications from being run,
> as it means a suspend has already been requested, which is not really the
> case after pm_request_resume().

Yes it is. A delayed suspend and an immediate resume have _both_ been
requested. We are within our rights to say that the resume request
gets fulfilled immediately (by doing nothing) and the suspend request
will be fulfilled later.

> > > No, it doesn't matter if the request runs, but it does matter if the work
> > > structure used for queuing it up may be used for another purpose. :-)
> >
> > What else would it be used for? If rpm_request_resume returns without
> > doing anything and leaves the status set to RPM_IDLE, then the work
> > structure won't be reused until the status changes.
> Which is not right, because we may want to run ->runtime_idle() before
> the status is changed.

If the status is RPM_IDLE then there's already a suspend request
queued. So what reason is there for sending idle notifications? The
whole point of idle notifications is to let the driver know that it
might want to initiate a suspend -- but one has already been initiated.

> That's why I think pm_request_resume() should queue up a resume request if
> a suspend request is pending.

Surely you don't mean we should suspend the device and then resume it
immediately afterward? What would be the point? Just leave the device
active throughout.

As long as the behavior is documented, I think it will be okay for
pm_request_resume not to cancel a pending suspend request.

Alan Stern

 \ /
  Last update: 2009-06-29 18:13    [W:0.055 / U:1.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site