Subject: Re: RFC: Device power management
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Jared D. McNeill <email@example.com>
Date: 07/16/2007 11:01:01
On Mon, 16 Jul 2007, Steven M. Bellovin wrote:
> I'm glad to see this; it will help a lot. A few thoughts...
> Disk drivers, at the least, need the ability to wait until many pending
> commands are finished, I suspect. Perhaps network devices do as well,
> but packet loss at such a time isn't a problem.
I was hoping that someone else could help me out in defining /
implementing policies for these subsystems, where I'm not quite as
familiar with how things work.
> A time delay should be added to some requests. dhclient already has
> problems with autonegotiation (especially 802.11 links, in my
> experience, but also gigE) because of how frequently it does ifconfig
> down/up cycles; this might make it worse. Disk drives can require a
> few seconds to spin up before they're ready; some component (I'm not
> sure which) is going to need to be cognizant of that delay.
Idle timeouts are currently in use for audio and display devices; this
shouldn't be an issue.
> There probably needs to be some notion of topology, so that things like
> USB hubs can be powered down at the right time. We may also need a
> user-level tool to check the power state of various pieces.
I forgot to mention in my first email that device pm handlers are attached
to device_t, so you should end up with proper topology for free.
To register a power handler, a driver does this at attach time:
status = devpm_register(self, bus, mydriver_power);
Typically the 'bus' arg is parent, but that may not always be the case.
What then happens, when the PM policy for a specific device requests that
it changes state, the following happens:
If bus is defined and we are increasing our power level
Turn parent bus on
Set state of device
Notify bus of state change
This way, a bus can scan all of its children and power itself down when
everything below it is turned off. The policy will then re-enable the
parent bus before enabling the device later on.
As for showing current power states from userland, we can probably use
/dev/drvctl for this.