On Sat, Jul 30, 2005 at 10:36:56PM -0400, Alan Stern wrote:
> An example will make this clearer. A PCI bridge is a parent, with a
> PCI device as its child. The set of device states for both the parent and
> the child is {D0, D1, D2, D3}. (Maybe some variants of D3 for special
> situations; let's not worry about the details.) The link states will
> also be D0 - D3. When the child want to go from D0 to D3, it first
> ^^^^^^^^
> changes the device's actual state and then notifies the parent about
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the link change.
> ^^^^^^^^^^^^^^^
Strong disagreement. Power state changes must be allowed to fail
("Spin up the 15K RPM drive? I'm sorry, there's only 3 Watts of power left
to spare"). So you must first ask the parent for a power state change
before you perform your own so it has the opportunity to deny the request.
Besides, in the case of USB, you may not have any power at all until you
notify the parent bus/hub manager to wake up.
> These notifications are one-way, child-to-parent only. We don't need
> pre- and post-notifications; each message will inform the parent of a
> single link-state change, which the parent will then carry out.
I don't see how this will work. Bringing up power/resuming must
happen in parent-to-child order, otherwise endpoint devices may not have any
power at all when you try to bring them up. Cutting off power/suspending
must happen in child-to-parent order, since parents can't know when it's
safe to cut off power until the child is completely quiesced.
> Idle-timeout RTPM: We certainly should have an API whereby userspace
> can inform the kernel of an idle-timeout value to use for
> autosuspending. (In principle there could be multiple timeout values,
> for successively deeper levels of power saving.) This cries out to be
> managed in a centralized way rather than letting each driver have its
> own API. It's not so clear what the most efficient implementation
> will be. Should every device have its own idle-timeout kernel timer?
> (That's a lot of kernel timers.)
Whether you do it in user space or kernel space, you're going to
potentially schedule a lot of timers.
> Or should the RTPM kernel thread
> wake up every second to scan a list of devices that may have exceeded
> their idle timeouts?
>
This could potentially make performance-conscious apps "hiccup"
once every second as this thread goes walking the list looking for
candidates to shut off. Try to avoid this; if nothing is happening, nothing
should be running.
> Userspace support: It's easy to see how userspace could use sysfs to
> request a single device state change. But what if the user wants to
> suspend an entire subtree? [ ... ]
If you wanted to get really fancy, you could establish via a
userspace API a named "device collection" which acts as a virtual device.
You then apply the state change to the device collection, and the kernel
percolates it through all the actual devices, taking locking into account.
Schwab
