lkml.org 
[lkml]   [2007]   [Jul]   [22]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateSat, 21 Jul 2007 23:49:43 -0700 (PDT)
    From david@lang ...
    SubjectPower Management framework proposal
    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@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2007-07-22 08:53    [from the cache]
    ©2003-2008