Power Management framework proposal

From: david
Date: Sun Jul 22 2007 - 02:50:47 EST


I'm deliberatly breaking the threading on this so that people who have tuned out the hibernation thread can take a look at this.

below is the proposal that I made at the bottom of one of the posts on the hibernation thread.

the idea is that instead of approaching power management from the point of view of the current desktop standard (ACPI), instead this approaches it from the point of view of 'what does a tool need to know to do the job' no matter what mechanism is actually used to implement the different modes.

one thing that I didn't put in the original post is that the framework that I mention below should work with other types of devices besides ACPI ones.

CPU clock settings could fit the same API for example (with modeID=0 being to hot-unplug the cpu and modeID=1 to initialize the cpu)

here's the original post:

in fact, a better abstraction would be something like

report_power_modes
which would return a series of modes (sorted only by modeID)
modeID, %power_used_in_this_mode, %capability_in_this_mode
(I would make mode 0 always be complete power off, and mode 1 always be full capacity)

report_power_mode_speed
which would return a matrix giving how long it takes to transition from any mode to any other mode. this should be a relative number, not an absolute number since it will be different at different clock speeds.

set_operational_mode(modeID)
which would take you from whatever mode you are in now to the requested mode.

most devices would report the simple list of modes

0,0,0
1,100,100

with a mode_speed matrix of
0 1
---
0|0 1
1|1 0

it may be that there is more info needed for the powr management engine to decide what modes it wants to put things into, if so identify what type of info you need and add another column to the modes list.
for example:
you may want to add a flag for 'does this mode allow downstream devices to operate?'
you may want to make a mode for 'this mode doesn't allow any new requests, but continues to process pending requests' and have a flag that indicates this

currently it looks like there's no way to find out what modes are available, and you have to know what mode something is in currently before you can request it change to a different mode. both of these prevent effective power management without encoding intimate knowledge of the capability of the particular hardware in your management tool.

some of this may be discoverable via the ACPI interface (it's not talked about much in the devices.txt file), but the mode setting is still wrong.

note that in the example above it's accpetable for a driver to cache what mode it thinks the device is in, but it needs to properly set the new mode even if it's cached data is incorrect.

this approach would allow the transition of ALL drivers to the new mode of operation in one fell swoop, and then adding additional power management features is just adding to the existing list rather then implementing new functions.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/