Subject: Re: PNP power management API for drivers
To: Joerg Sonnenberger <>
From: Matt Thomas <>
List: tech-kern
Date: 10/05/2007 18:20:59
On Oct 5, 2007, at 2:35 PM, Joerg Sonnenberger wrote:

> On Fri, Oct 05, 2007 at 02:24:01PM -0700, Matt Thomas wrote:
>>> said:
>>>> bool pnp_device_register(dev_t, bool (*suspend)(dev_t),
>>>>     bool (*resume)(dev_t));
>> is dev_t supposed to be device_t?
> Yes.
>> How do you control which D1,D2,D3 state to suspend to?
>> register should indicate which states are supported?
> At the moment it is up to the bus handler to use whatever it wants.
> The first implementation would use D3hot for all PCI devices that
> support PCI-PM. Once the device property support is merged, it  
> would be
> adjustable on a per-device base. This will likely go hand-in-hand with
> an extension of the bus API. But I want to defer that discussion to  
> the
> right point.

OK.  We can defer that for now.

> I don't think register has to include the supported states as they are
> either trivial (just on or off) or need some bus support. I don't  
> think
> complicating the API is justified at the current time.

One problem with the ABI it that for one platform, you may be to power
on a device before it can be probed/attached.  I don't see how to
accomplish that with the current ABI.  The other thing I don't see is
aggregation of devices into the same power domain (which is orthogonal
to what bus it lives on).  I think that the idea of power domain and
bus needs to be separate.

>> How do you deal with, say, an audio device which is inactive
>> so it wants to automatically powers itself down?  does it need
>> to go through the system pnp calls or can it do a private suspend
>> behind the system's back.
> The device itself should do nothing of that sort. That's what the  
> device
> classes and handlers are for. I have an experimental patch for the
> jmcneill-pm to power down a network interface if it is not IFF_UP.

I'm thinking of a cell-phone.  Once a device goes idle, it should be
powered down (assuming that power-on/power-off is small enough to not
noticeable in human reaction time).  If I'm not sending audio, I want
the audio powered off.  When there is something to be played, I want
to turn audio on.  Are you saying this would be done at in the audio
class layer?

> Jared wants to do similiar things for the audio devices. In  
> general, the
> decision about when to power down or not should be left for higher
> layers to decide. A device is certainly not the right place.

My target is different from the usual laptop and I don't that the
statement can be generalized to all platforms.