[RFC] Mapping Device Power States

[RFC] Mapping Device Power States

[Adam Belay]

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


Linux supports a wide variety of hardware, each with different power
management characteristics and capabilities.  However, power management
statistics (e.g. calling a power tick for determining an idling) are
generally gathered at the class device level.  In order for class
devices to relate bus specific power states to their own state change
intentions, it may make sense to have a table mapping each bus level
power state to its corresponding generic Linux power state.

Another problem with having multiple separate states is that it is very
difficult to relate the power requirements of child devices when the
parent has a different set of bus level power states.

I would like to explore the possibility of defining a set of generic
power states, to which each bus level state can be mapped.  It might be
as follows:

functional - the device is operational.
context - the current data/operations passing through the device
configuration - resources, firmware, settings done in *probe, etc.

POWER_ON: the device is fully functional
POWER_LIGHT: device context and configuration are maintained, but device
isn't functional.
POWER_MODERATE: device configuration is maintained, but the context is
not.  The device isn't functional
POWER_DEEP: no device configuration or context is maintained, but device
is not fully off.  The device is not functional.
POWER_OFF: no power is applied to the device.  The device is not
functional.

Each lower state would save more power, but also require more latency
when returning to "POWER_ON".  When a device is in one of the above
specific power mode classes, it's up to the device driver to control
more fine grained power transitions.

Comments?

Thanks,
Adam



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

Re: [RFC] Mapping Device Power States

[David Brownell]

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

On Thursday 07 April 2005 2:25 pm, Adam Belay wrote:
> 
> Linux supports a wide variety of hardware, each with different power
> management characteristics and capabilities.  However, power management
> statistics (e.g. calling a power tick for determining an idling) are
> generally gathered at the class device level.  In order for class
> devices to relate bus specific power states to their own state change
> intentions, it may make sense to have a table mapping each bus level
> power state to its corresponding generic Linux power state.

I'm not clear on that "In order for ...".  For one thing, class
devices aren't necessarily relevant.  For another, it presumes
the notion of a "generic" (device) power state.

But I guess my fundamental question is:  why should anything other
than its driver want to know about the device's power state?

System suspend transitions can all be handled by a "make yourself
compatible with this target system state" request.  The details of
how that's done are irrelevant outside the drivers.  Likewise,
runtime/dynamic/whatever power management operations can be done
at any time ... in fact, I'd argue all hardware should stay in
low power modes until it's actually needed, and entering higher
power modes should normally be transparent.  (So that if they
are stupid and stay in high power modes all the time, the only
penalty is wasted power.)


> Another problem with having multiple separate states is that it is very
> difficult to relate the power requirements of child devices when the
> parent has a different set of bus level power states.

That's a partial answer to my question:  sometimes a "container"
needs to coordinate power states of several devices.  OK; they
may have private agreements.  (A "bus" might be a "container",
but not all containers are busses.  Some are bridges, or hubs,
and some are less regular components involving multiple sorts
of control, data, and power connection.)

Of course, the current PM models in Linux don't exactly have such
a "container" model.  We've discussed needing child-to-parent
notificatios at various points, and those would be part of such
a model.


> I would like to explore the possibility of defining a set of generic
> power states, to which each bus level state can be mapped.  It might be
> as follows:
> 
> functional - the device is operational.
> context - the current data/operations passing through the device
> configuration - resources, firmware, settings done in *probe, etc.

The only one of those that seems needed outside of the driver
itself is whether it's "functional".  The rest are private to
the driver or maybe its container.


In short:  why should there be any Linux-wide notion like that?
Wouldn't trying to create one just be the problem of creating a
"Grand Unified Theory of Power Management"?

- Dave

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

Re: [RFC] Mapping Device Power States

[Benjamin Herrenschmidt]

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

On Thu, 2005-04-07 at 15:04 -0700, David Brownell wrote:


> In short:  why should there be any Linux-wide notion like that?
> Wouldn't trying to create one just be the problem of creating a
> "Grand Unified Theory of Power Management"?

Hrm...

Each time somebody comes up with an attempt at providing a generic model
that could be useful enough for most driver, you come up with your
"grand unified bla bla bla" argument as a way of dismissal... not very
constructive.

Ben.



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

Re: [RFC] Mapping Device Power States

[David Brownell]

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

On Thursday 07 April 2005 4:56 pm, Benjamin Herrenschmidt wrote:
> On Thu, 2005-04-07 at 15:04 -0700, David Brownell wrote:
> 
> > In short:  why should there be any Linux-wide notion like that?
> > Wouldn't trying to create one just be the problem of creating a
> > "Grand Unified Theory of Power Management"?
> 
> Hrm...
> 
> Each time somebody comes up with an attempt at providing a generic model
> that could be useful enough for most driver, you come up with your
> "grand unified bla bla bla" argument as a way of dismissal... not very
> constructive.

But that doesn't answer my question now, does it?

Talk about dismissal... I've mentioned that twice now.  Yours is
a strange reaction, given that level of exposure.  Maybe it's
just too darn close for comfort?

I _do_ happen to think that much of the reason the power management
stuff has stayed such a mess is that folk have been aiming towards
a "grand scheme", and that such a thing is counterproductive.  To
have this work, things need to be decentralized, not micro-managed.


The specific question Adam asked is something I've been thinking
about off and on.  It relates to the issue of what should happen
to the sysfs power/state files.

To perhaps oversimplify things, Adam asked how to change the current
"there is such a global state" model ... and my response was more
at the level of a "that seems like the wrong model, what's the real
problem you want to address?" question.

Maybe there really is something essential in such a global model.
If that's the case, my questions will have good answers...


It's not "constructive" to attack someone for asking honest
questions now, is it???



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

Re: [RFC] Mapping Device Power States

[Li Shaohua]

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

On Fri, 2005-04-08 at 05:25, Adam Belay wrote:
> 
> POWER_ON: the device is fully functional
> POWER_LIGHT: device context and configuration are maintained, but
> device
> isn't functional.
> POWER_MODERATE: device configuration is maintained, but the context is
> not.  The device isn't functional
> POWER_DEEP: no device configuration or context is maintained, but
> device
> is not fully off.  The device is not functional.
> POWER_OFF: no power is applied to the device.  The device is not
> functional.
I think there are two POWER_OFF. One is the device is not functional but
its related device such as PIC is enabled. And the other is its related
device is disabled. In STR, the state of a device is it's powroff and
its related devices such as the pic/ioapic pin and irq router is are
disabled/masked.

Thanks,
Shaohua


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