Re: RE: on-ness

[David Brownell <david-b@pacbell.net>]

[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]

On Monday 24 April 2006 2:32 pm, Woodruff, Richard wrote:

> The current pseudo export 
> of these non-functional states doesn't seem so useful.  Having some
> fuzzy level of idleness seems much better.

I've come to believe that userspace has little or no business caring
about the details of power states ... except to the extent that a driver
exports them.  After all, the driver might not support all the possible
hardware states.  And the same controller on two different systems might
expose different power management functionality, based on (among other
things) what external hardware is wired up.


> The point of the idle states Len was floating attempts to define a level
> of on-ness/idleness.  As it turns out there was a nice correlation to
> some ACPI states.  Numbering them seems reasonable, else your just
> wasting effort translating 'state0, state1, state2, ...', keeping the
> naming convention simple '0,1,2,..0xffff' would seem to lend itself to
> code sharing of necessary class/device specific translation code.

I don't think I agree with "seem".  We'd get right back into the mess
we now have ... not just expecting "2" to mean the same thing everywhere
(aargh!) but also finding needs for integer "1.5" that is somehow stuck
between "1" and "2".  Much easier to do that with strings!

Plus, numbers lead to an assumption that things can be compared.
One is less than two ... but is an apple less than an orange?
In the same way, different power states are not necessarily
comparable on one single axis.

  
> > Actually the wakeup characteristics are orthogonal, there are
> > per-device bits controlling whether a device can and should do
> > the wakeup.  We don't for example treat "PCI_D3hot with wakeup"
> > as a distinct state. 
> 
> In my current hack attempts I am trying to associate a 'device' D2 state
> with a local device sleep with an async wake up enabled.  In this state
> a devices accesses are locked out until the device wake up event
> happens.  This async wake can be from a device specific wake up or from
> an associated timer resource.

So would that be a "wake the whole system" or a runtime power
management mechanism to provide functionality without very much
of a power drain?  I've done the latter a few times, but never
needed to expose it through sysfs.  If it works, it kind of needs
to be enabled at almost all times, to avoid nightmares of config
management and debugging.

- Dave



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]