Subject: pmf(9): shutdown & D1/D2 states
To: None <>
From: David Young <>
List: tech-kern
Date: 12/23/2007 15:10:14
I would like to get some feedback on changes that I would like to make
to the power management (PM) framework, pmf(9), to support D1 and D2
power-saving states and wake-up events, and also to distinguish device
shutdown from device suspension.

I have integrated some ideas from Jared McNeill and Joerg Sonnenberger,
but that does not necessarily mean that they endorse my ideas or my
interpretation of their ideas.  All dumb ideas are mine. :-)

* Shutdown

Shutdown and suspend are not the same state, and we can avoid some work
at shutdown time if we skip a full suspend on most devices, so I propose
to let devices supply an optional third PM callback:

        pmf_device_register(device_t dev, bool (*shutdown)(device_t dev),
            bool (*suspend)(device_t dev), bool (*resume)(device_t dev));

* D1/D2 States: D1

According to my understanding of D1 state (Jared McNeill filled me in),
it is a power-reduced state where the device state is not lost.  A device
may reduce its capacities in D1 state, but it is still operational.

According to this definition, an 802.11 adapter in D1 state may switch
to 802.11 power-save mode: it powers-down its transmitter & receiver,
but it stays associated with a network.  It powers up both xmtr and rcvr
when there is something to transmit, and it powers up its rcvr at periodic
awake times.  In this way, it stays connected, but it is a bit sluggish.

I propose to add an optional PM callback that tells a device to enter
D1 state.  Perhaps the name D1 is too obscure.  Let us call the callback
save_power, for now:

        pmf_device_register(device_t dev, bool (*shutdown)(device_t dev),
            bool (*suspend)(device_t dev),
            bool (*save_power)(device_t dev),
            bool (*resume)(device_t dev));

* D1/D2 States: D2

D2 is a power-reduced state where some device state may be lost.
I believe that the importance of D2 state is two-fold: some devices will
still produce wake-up events in this state, and some devices wake more
quickly from D2 state than from D3 state.  D2 is a "light sleep."

It may be useful to put a NIC into D2 state for the greatest power-saving,
while its wake-on-LAN functions remain active.

Let's add an optional callback for D2 state, too, called sleep_lightly:

        pmf_device_register(device_t dev, bool (*shutdown)(device_t dev),
            bool (*suspend)(device_t dev),
            bool (*sleep_lightly)(device_t dev),
            bool (*save_power)(device_t dev),
            bool (*resume)(device_t dev));

* Device Properties 

Joerg Sonnenberger reminds me that a PM policy engine may want to
set each device's power state in order to meet certain goals, such
as minimal wake delay.  Another goal might be power savings.  If and
only if a device can supply a reliable value, it should set a device
property that tells a power-state transition times, its power savings.
Here are some sample properties that might be helpful:

        pmf-d0-d3-savings-uw    D0 power savings: D3 power consumption
                                minus D0 power, in microwatts (units?)
        pmf-d1-d3-savings-uw    D1 power savings
        pmf-d2-d3-savings-uw    D2 power savings

        pmf-d0-d3-trans-us      time to wake to D3 state from D0 
        pmf-d1-d3-trans-us      from D1
        pmf-d2-d3-trans-us      from D2


David Young             OJC Technologies      Urbana, IL * (217) 278-3933 ext 24