On Fri, Oct 05, 2007 at 06:20:59PM -0700, Matt Thomas wrote:
>> 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. 

It is not meant to part of it. Again, I think this is a different
problem domain and generally the job of the bus driver. The device
driver itself doesn't exist at this point, so it can't even be part of
the decision. This is one of the nastiest parts of the current
dev/cardbus -- a lot of drivers have to reimplement functionality that
should be the job of the infrastructure.

> 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.

I know that there are interactions between devices. This gets into the
part of MD interfaces though. E.g. ACPI enumerates the different power
domains, not sure about other platforms. I think this is similiar to
handling deeper sleep states though -- without an infrastructure to keep
the device relations in one place this can't be done. It also affects
only the bus drivers and not so much the device drivers. Basically the
bus driver interface has to support putting devices into deeper sleep
states incrementally and based on the global policy. For the rest it
doesn't have to care.

>> 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?

Yes. More precise, we should identify this kind of driver classes and
create the proper infrastructure. A driver shouldn't have to be changed
for the application domain and the policy of how aggressive power
management should be done depends a lot on that and can even change,
e.g. if AC is connected.

>> 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.

I don't think one policy fits all. But that is exactly the reason why
the driver is the wrong place to decide this.

Joerg