System sleep vs. runtime PM

Alan Stern
2009-12-02T18:35:34Z

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).

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?

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.)

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?

If a remote-wakeup request should abort the system sleep, how do we
make this happen?

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
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.)

This suggests that the safest course is for dpm_resume() to
automatically do a pm_runtime_resume() on every device. Is this
drastic overkill? Should we keep a record when we fail a
runtime-resume during a sleep transition and then runtime-resume only
those devices?

Then there's the whole sticky question about how to handle devices
whose runtime-wakeup and system-sleep-wakeup settings need to be
different. In many cases the setting can't be changed unless the
device is at full power. Such devices would always need to be
runtime-resumed both before and after every system sleep (during
the prepare and complete phases). Should the bus subsystem be
responsible for this? (Don't forget that during the prepare phase, the
device's state will be DPM_PREPARING and so the bus subsystem won't be
allowed to do a runtime resume.)

There's probably a good deal more to discuss, but this is all I can
think of at the moment.

Alan Stern