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
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
