Re: System sleep vs. runtime PM

[Oliver Neukum <oliver@neukum.org>]

Am Mittwoch, 2. Dezember 2009 19:35:34 schrieb Alan Stern:
> Rafael and Oliver:
> 
> I'm in the midst of converting USB over to the runtime PM framework,
> and I'm getting stuck on the interaction between system sleep and
> runtime PM.  In fact, I'm so confused about it that it's hard to
> formulate a coherent set of questions.  So bear with me...
> 
> If a driver gets an output request and its device is runtime-suspended,
> then the driver should do a runtime-resume before sending the output to
> the device.  If the output request arrives during a system sleep
> transition then the output should be refused or left to sit in a queue
> (presumably this won't happen, but it might).

How can it happen? As the freezer has run before drivers learn
about a sleep transition, the request would come from a kernel thread.

> However this requires the driver to know when a system sleep is in
> progress -- it's not enough merely to know whether the device is
> suspended.  We could make things easier for the driver by failing
> runtime-resume requests when the device's power.status isn't DPM_ON or
> DPM_RESUMING.  Does that make sense?

That is not a good idea as it needs error handling in all drivers
for a rare corner case. That's bound to cause many bugs.

> But then what about remote wakeup?  The arrival of a remote-wakeup
> request during a sleep transition has always been problematic.  Should
> the request be allowed to abort the sleep transition?  (Once the kernel
> is aware of the request, it is probably no longer stored in the
> hardware so it won't wake the system back up as soon as we go to
> sleep.)

It should abort the sleep if the device would wake the system from sleep.

> What if the device is enabled for runtime remote wakeup and not for
> wakeup from system sleep?  There will be a window during which the
> wakeup settings are wrong.  Should a wakeup request from such a device
> be allowed to abort a sleep transition?

The core should prevent that window. If necessary devices with
different wakeup settings should be resumed before starting system sleep.
 
> If a remote-wakeup request should abort the system sleep, how do we
> make this happen?

Good question. I have no answer.

> If a remote-wakeup request doesn't abort the system sleep, then what
> happens to it?  Obviously it should get serviced when the system wakes
> up again.  But what if the device was runtime-suspended when the sleep
> began?  How do we make sure it gets runtime-resumed when the sleep
> ends?
> 
> I can see two possibilities here.  One is that the remote-wakeup
> request triggered an asynchronous pm_request_wakeup().  In this case
> the request is sitting on the PM workqueue and it will automatically be

That sounds very reasonable.

> satisfied after the system wakes back up.  The other possibility is
> that the request triggered a synchronous pm_runtime_resume().  If this
> fails because a sleep transition is in progress, the request will get
> lost.  (The same sort of thing happens when output requests get stuck
> in a queue and the runtime-resume fails.)

That must not happen.

	Regards
		Oliver