On Mon, 16 Jul 2007, Matthias Drochner wrote:
> jmcneill@invisible.ca said:
>>   3. Eventually, nuke the powerhook_establish/powerhook_disestablish
>>      framework
>
> Great - this doesn't deal with hierarchical buses and needs to die.

I forgot to mention that devpm is attached to device_t, so we get 
heirarchy for free.

>> device class policies along with a sample power
>> management handler for the wskbd(4) driver (input class), azalia(4) (audio
>> class), and vesafb(4) (display class).
>> [...]
>> Audio devices are transitioned to D0
>
> As I understand, you are using the ACPI nomenclature for device
> states here. That's reasonable because it comprises some common
> ground, but the namespace used should be made obvious everywhere.
>
> For user-visible actions, entities like up/suspended/hibernated
> should be used which are translated to ACPI states where ACPI is
> in control, and to bus/device specific states otherwise.

For global system state, I agree -- common names should be used.

> Power management of eg PCI(express) and USB lives in different
> namespaces. These use the same letters to designate states, but
> there are nontrivial dependencies eg between power states of buses
> and devices.
> We should obey the namespace everywhere and translate explicitely
> where necessary. Otherwise we'd get a lot of ambiguities to
> be solved at the driver level.

DEVPM_STATE_D0/D1/D2/D3 are merely symbolic names used by the power 
management framework; power handlers are responsible for translating these 
symbolic names to names relevant for their bus.

In the PCI case, I have provided functions to translate devpm states to 
PCI states. We can do the same for other busses as well.

What happens today when a policy requests a bus to change state is that if 
the state is increasing, the bus is first sent a request to transition to 
D0. The policy then requests that the device transition to its new state. 
Finally, the bus is notified of a state change of one of its children, and 
may perform additional actions (such as powering down itself if capable).

Cheers,
Jared