Subject: Re: PNP power management API for drivers
To: Joerg Sonnenberger <email@example.com>
From: Matt Thomas <firstname.lastname@example.org>
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:
>>> email@example.com said:
>>>> bool pnp_device_register(dev_t, bool (*suspend)(dev_t),
>>>> bool (*resume)(dev_t));
>> is dev_t supposed to be device_t?
>> 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
> 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
> 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
> 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
> 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.