PowerPolicyManagement
Differences between revisions 8 and 9
|
Size: 16430
Comment:
|
Size: 6820
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Overview = == Introduction == Power optimization for PC Architecture is vastly different from that for embedded systems such as ARM based PDAs or Cell phones. This is because each embedded chipset has its own unique set of power management features that require a custom flavor of linux built from the ground up. PC based chipsets already have a well established code base in linux, with existing hardware interfaces such as ACPI and HAL; and as they have evolved from desktops into smaller, more portable systems, a wealth of software packages have been created to optimize power. |
##(see the SpecSpec for an explanation) |
| Line 5: | Line 3: |
| Each of these packages can be thought of as a power micro-policy controller for a specific subsystem on a linux based platform. For instance cpufreq manages power for the CPU supsystem, or the iwconfig interface manages device specific power for the Network (WLAN) subsystem. Currently all these micro-policy managers function independantly of one another and with little or no information from the user domain. Thus there are two things lacking in linux with regard to power. The first is a centralized policy manager which can gather input from ACPI, the user, and running applications to generate a complete picture of how the device is being used. This information can be used to create macro-policies which can selectively tune or override the systems micro-policy managers to achieve far greater power optimization. The second piece missing is a scheme to create micro-policy managers for all power-hungry subsystems that dont currently support any form of control.[[BR]] |
''Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.'' * '''Launchpad Entry''': UbuntuSpec:PowerPolicyManagement * '''Packages affected''': ppm == Summary == The Power Policy Manager (PPM) is a layered, system-wide power policy framework. Most power managers assume a binary power policy. For example, they change power policies when AC power is removed, but don’t provide a way for users to override these settings. Many policy managers that do provide user choice attempt to hardcode exceptions, and do not provide a way for users to select multiple power policies.[[BR]] This functional specification proposes the addition of PPM package into the UME apt repository to solve the Mobile-Internet-Device specific power policy needs.[[BR]] == Release Note == By adding the ppm implementation, a new mechanism for defining device power profiles will be added to the UME technology pool. For the most part the operations of the PPM will be seen by the end user, but eventually new control panel applets and/or status bar indicators could provide additional controls and/or information about the device power state. A classic example would be a control panel applet that would provide a UI for placing the device into "Airplane Mode", which would trigger the device to turn off all radios (per federal air regulations) and also enable various low level power saving settings to enable the end-user to use their device for as long as possible. == Rationale == What is needed is a flexible power policy manager that allows users to select multiple policies, and easily modify those policies to fit their system. The system should leverage existing system power management capabilities, such as Advanced Configuration and Power Interface (ACPI). It should also allow users to write their own power management code for new hardware. Most importantly, it should be a system-wide policy manager that focuses on more than just the CPU frequency.[[BR]] == Use Cases == |
| Line 9: | Line 27: |
| * Macro-policy focus is on the usage model * Where is the user and device (e.g. stationary vs moving, near to vs from from a power source, inside or outside) * When is the device being used (e.g. night vs day) * How is the device being used (e.g. is the user listening to it, looking at it, controlling it) * What is the device being used for (e.g. using network, playing audio, displaying video, high vs low performance) * Micro-policy focus is on the subsystem and driver level * Groupings by power optimization capability * CPU (single or multi-core) * Network (LAN, WLAN, WWAN) * Storage (Harddisk, Flashdisk, DVDROM) * Human Interface Devices (Mouse, Keyboard, Touchscreen) * Video (LCD, Graphics card) * Audio (Speakers, Headphones, AC97, HD Audio) * Wireless Connections (Bluetooth, GPS) |
== Assumptions == |
| Line 24: | Line 29: |
| == Architecture == The power policy manager for linux is meant to be a universal, cross-platform framework for reducing power consumption in linux based devices; with particular focus on handhelds. It is implemented in three parts: a configuration data layer, a micro policy engine control layer, and a daemon that ties the two together. * '''Configuration Layer''': Provides “configuration element” messages from a GUI, applications, and system agents which describe the optimization potential in the system. e.g. user focus, device position, handling, and movement, and application needs. The Configuration Element Interface (CEI), will be based on Dbus and can be used by applications or a GUI to provide usage model information to our power manager daemon. Usage model info is intended to help us understand where, when, how, and for what purpose the device is being used. These attributes can help us intelligently regulate power and performance to match the users neds and expectations. * '''MPE Layer''': Provides “tunable element” control access to all the subsysems on the platform. e.g. LCD brightness, Audio codec, etc. The MPE Interface (MPI), will be used to control any subsystem micro-policy managers which are already available to us. Subsystems are determined as a collection of devices which serve some common purpose that can be optimized for power cleanly. Micro-policy engines will exist for each subsystem we intend to control. * '''PPM Daemon''': Defines what groupings of configuration elements are configuratble from the GUI, and the mappings between configuration and tunable elements. attachment:C__fromlaptop_ppm_small.jpg == Constraints == * Must be as generic as possible for use across multiple linux based platforms * No dependence on knowledge of specific applications or drivers * Should exist entirely in user space so there's no kernel dependency * Use C as the default programming language * Leverage established linux protocols and interfaces wherever possible * Should communicate with applications and GUI through a Dbus interface. * Should use ACPI for system event notification = Configuration Input Layer = == Configuration Element Interface (CEI) == The CEI will be implemented as a simple DBUS function call using the [http://dbus.freedesktop.org/doc/api/html/index.html glib-dbus]; wrappers. With this strategy, an xml file is created which describes the function: {{{ <node name="/PPM"> <interface name="com.intel.cei"> <method name="SendConfigurationElement"> <arg type="s" name="config_element" direction="in" /> <arg type="s" name="target" direction="in" /> <arg type="s" name="svalue" direction="in" /> <arg type="i" name="ivalue" direction="in" /> </method> </interface> </node> }}} Using the dbus-binding-tool provided by glib we can then create a server and client header file that enables the usage of this function. The function will look like this: gboolean send_config_element(DBusGProxy *proxy, char *element, char *target, char *svalue, int ivalue); * Element: is the string name of a predefined config element that the PPM Daemon will accept. * target: is the specific hardware target of the config element (hda1 for instance if there are more than one hd) * svalue: is the string data value, which is designed to be general and user friendly (like low, med, high) * ivalue: is the numerical data value, which is designed to be very specific (like X percent or X kbps) The PPM Daemon will act as the server and the single receiver of the function call, and any number of applications or a GUI can act as clients by sending elements out through this function. The ppmd server is called through the DBUS server connection, and therefore must have the proper configuration files in place for the DBUS daemon to allow it to run. == Configuration Element List == These data points represent very specific conditions which ''may'' affect power or performance. Some can be used immediately for obvious purposes, but some are just there as placeholders for some future benefit. The user will likely never provide this information manually at this level. Usage model data at this granularity will be provided by the system (ACPI, HAL, Applications, or the GUI in the form of a macro). Each type of input can be broken down into a set of specific "configuration elements" which are what is actually sent across DBUS. === User Focus === These refer to how the user will interact with the MID. These represent the only things that the user MUST tell us. * Visual Attention * no visual (e.g. listening to a playlist of music) * intermittent visual (listening to music and picking songs) * constant visual (e.g. watching a video, playing a game) * Aural Attention * no audio (e.g. without headphones in a public place) * intermittent audio (e.g. waiting for IM alert) * constant audio (e.g. listening to music or watching a video) * Device control * no interaction (e.g. watching a movie, or listening to a playlist of music) * intermitent interaction (e.g. browsing the web, pausing to read) * constant interaction (e.g. playing a game) * Target Battery Life * 1 hour (e.g. just enough for a meeting or class) * 2 hours (e.g. just enough to watch a movie) * 4 hours (e.g. just enough for a plane ride) * 8 hours (e.g. enough for a work day) * maximum (as much as possible) ||'''Config Element(string)'''||'''Target(string)'''||'''Value(string)'''||'''Value(int)'''|| ||videofocus||lcdmon,extmon,exttv||none,rare,intermittent,often,constant||X ms (reaction time needed)|| ||audiofocus||speakers,headphones,ext||none,rare,intermittent,often,constant||X ms (reaction time needed)|| ||userinput||keypad,mouse,touchscr,camera||none,rare,intermittent,often,constant||X ms (reaction time needed)|| ||tgtbattlife||all||1hour,2hour,4hour,8hour,max||X minutes til off|| |
* Device provides some mechanism for regulating power hungry devices. This could be something as common as ACPI, or as unique as a custom micro-controller with a ad-hoc interface for programing from the Linux system running on the CPU. |
| Line 104: | Line 32: |
| === Device Position === These refer to the physical position and state of the MID. They are things that for the most part the user will have to enter, but we can work to make most of these automatically detected. |
== Design == |
| Line 107: | Line 34: |
| * Device movement * stationary * moving * slowly (e.g. walking, jogging) * intermittent high speed (e.g. in a car driving and stopping) * constant high speed (e.g. in a plane or train) * Proximity/Accesstime to power source or wifi connection * Plugged in (ACPI event) * AC wall socket * DC Car jack * DC Airplaine jack * DC Solar Charger * External Battery * X minutes until power source/wifi available (ETA) * immediately (e.g. in a car, at home, airport terminal) * < 20 (e.g. in transit between home and work) * < 120 (e.g. general mobile usage) * < 240 (e.g. a standard plane ride in coach) * < 480 (e.g. a standard college school day) * very large (e.g. on a camping trip) * X minutes until power source/wifi no longer available (ETD) * < 30 (e.g. charging at airport lounge, plane leaves soon) * < 120 (e.g. charging while at a restaurant) * < 480 (e.g. charging the night before) * very large (long period of outlet usage) * Device handling * is in a stable position (e.g. on a desk or on someones lap) * is being jostled (e.g. held while walking, or in a backpack) * Geographic Location (user input or GPS detection) * Country (e.g. for cellular standards, radio freq ranges) * Rural vs Urban (e.g. likelihood of cell tower or recharge) * Proximity to cell towers (e.g. if one had a tower map) * On Land vs Water (e.g. likelihood of cell tower or recharge) * Elevation (e.g. too high for cellular) * Radio Signal restrictions * outside * with full sky view (e.g. in a rural area, or on the ocean) * with partial sky view (e.g. amongst trees, or in the city) * inside * small structure (e.g. house, car, plane) * large structure (e.g. an office building, or a mall) * underground (e.g. a long tunnel, or subway) * forbidden (e.g. on a plane) * Ambient light * Midnight (e.g. total darkness, LCD backlight on very low) * candlelight (e.g. dim lighting, LCD backlight on low) * officelight (e.g. standard lighting, LCD backlight off) * daylight (e.g. high lighting with glare, LCD backlight on medium) * sunlight (e.g. highest lighting and glare, LCD backlight on full) |
The Framework The PPM breaks down power policy management by using plug-ins, layers, and modes. * Modes determines which layers to use. * Layers contains the list of commands. * Plug-ins communicate the commands to the hardware. [[BR]] A mode contains the list of which layers to activate. Multiple modes can be active at the same time. If two modes select different layers, the commands sent to the plug-ins will be based on a combination of the layers. Higher priority layers take precedence. [[BR]] For example, if one layer had the plug-in command, "cpu performance max", but a higher priority layer had the plug-in command, "cpu performance cool", the latter command would be sent to the cpu plug-in. Layers are transparent, which means that commands from lower priority layers that don�t overlap with commands from higher priority layers, are active. [[BR]] A policy layer is a grouping of plug-in commands, with an associated priority. [[BR]] Example layer 1 For example, a low-power layer might contain commands to: * set the CPU to a low-power mode * set the screensaver timeout to 2 minutes * dim the screen [[BR]] Example layer 2 A second layer, dealing with thermal issues, might: * set the screensaver timeout to 30 seconds * put the SATA hard drive into low power mode * tell the CPU to go into "cool" mode |
| Line 157: | Line 55: |
| ||'''Config Element(string)'''||'''Target(string)'''||'''Value(string)'''||'''Value(int)'''|| ||radios||BT,Wifi,Wimax,GPS||forceoff,allowon||0, 1|| ||extpower||outlet,battery||ac,car,plane,solar,extbatt||X mw (total charge capacity)|| ||ETA (Estimated Time of Arrival)||outlet,celltower,wifihotspot||1hour,2hour,4hour,8hour,max||X minutes to target|| ||ETD (Estimated Time of Departure)||outlet,celltower,wifihotspot||1hour,2hour,4hour,8hour,max||X minutes at target|| ||ambientlight||all||midnight,candlelight,officelight,daylight,sunlight||X % of direct sunlight|| ||movement||all||still,walk,jog,bike,car,train,plane||X meters per minute|| |
[[BR]] Which layer takes precedence? The thermal policy layer would have the highest priority, to make sure that the system doesn't overheat. [[BR]] Code example A layer file would look something like this (first release is simple text description): * File name convention: Priority_Name (for example: 00_default) * Policy file structure is three columns and N number of rows. * First column is CLASS, referring to device classes. * Second column is COMMAND, referring to operation to be invoked on the device or subsystem. * Third column is VALUE, such as ON, OFF, MAX (depending on the device). [[BR]] Layer content An example of the 00_default policy: CPU Performance Max radio radio allowed wifi radio on display screensaver user display brightness 50 bt radio off |
| Line 166: | Line 75: |
| === Time of Use (System Clock) === These are just examples of what the PPM can do if it knows the date and time. The input here is just the system clock. |
== Implementation == |
| Line 169: | Line 77: |
| * Time of Day * User specified (e.g. meeting times for audio shuttoff) * Night vs Day (e.g. for lighted panels or backlight) * Sleeping vs Awake (e.g. alarm volume or do not disturb) * Day of Week or Month * User specified (e.g. for TV recordings, or quicken updates) * Workday vs Weekend (e.g. unused during the weekends) * Time of Year * User specified (e.g. holidays where the device can be offline) * Season (e.g. could be used to determine temperature) |
The source tree for the ppm is available in a public git tree via: http://www.lesswatts.org/repos/projects/ppm.git/ |
| Line 180: | Line 80: |
| ||'''Config Element(string)'''||'''Target(string)'''||'''Value(string)'''||'''Value(int)'''|| ||DATE||all||local date||-|| ||TIME||all||local time||-|| |
The implementation is split into: * daemon: PPM service launched at system startup * ppmtool: command line tool for configuring the ppm deamon * plugins: PPM plug-ins that receive power policy commands and then interpret those commands to specific actions * layers: power policy configuration files * modes: configuration files that group sets of layers together |
| Line 184: | Line 87: |
| === Application === These refer to what the MID and its devices are being used for. All of this should come from device input rather than from the user (i.e. from the application itself). |
|
| Line 187: | Line 88: |
| * Application * Process IDs (e.g. focus all performance on a few select apps) * Network * On vs Off (e.g. at the office vs on a plane) * intermittent vs constant (e.g. email vs streaming audio) * transmition speed needed (e.g. align with audio stream) * CPU * Percentage Performance Needed (e.g. a game could monitor FPS and gradually increase or decrease CPU performance as needed to reach a target FPS) * Performance Heuristic * Constant (e.g. for a game) * Intermittent (e.g. for internet browsing) * Rare (e.g. for audio decode/playback) * ACPI * Is the AC adapapter connected * if the battery inserted * Is there a "lock" switch for keypad or mouse input |
=== UI Changes === |
| Line 204: | Line 90: |
| ||'''Config Element(string)'''||'''Target(string)'''||'''Value(string)'''||'''Value(int)'''|| ||cpu||CPU0,CPU1,...||off,low,med,hi,max||X % of max perf needed|| ||appfocus||pid (process id)||none,rare,intermittent,often,constant||X % of full user attention|| ||network||LAN,WLAN,WWAN||none,rare,intermittent,often,constant||X kbps of bandwidth|| ||acpi||outlet,battery,keypad,mouse,touchscreen,radios||enabled,disabled||1,0|| |
The PPM package does not present a UI, but as soon as the PPM is available in UME then a moblin-applets control panel applet will be added that allows the user to set airplane mode. |
| Line 210: | Line 92: |
| == Configuration Element Groups == | === Code Changes === |
| Line 212: | Line 94: |
| For ease of use, we will provide a configuration file that defines sensible groupings of configuration elements. The element set can be broken into two general types of "modes": usage modes and location modes. These groupings can be sent through the configuration element interface using "usagemode" or "locationmode" as the config element argument, and the name of the mode as the target argument (the value arguments will be ignored). | This is all new code. |
| Line 214: | Line 96: |
| === Usage Modes === | === Migration === |
| Line 216: | Line 98: |
| The usage mode will capture what the main application is, what the user's focus is, and what devices are needed for the usage mode to function. These can be editted manually by a user but will require a daemon restart for them to be recognized. Some examples are as follows: | N/A since this is all new code. |
| Line 218: | Line 100: |
| {{{ usagemode MUSIC-LOCAL { appfocus=realplayer videofocus=none audiofocus:headphones=constant audiofocus:speakers=none userinput=rare network=none } |
== Test/Demo Plan == |
| Line 228: | Line 102: |
| usagemode MUSIC-STREAM { appfocus=realplayer videofocus=none audiofocus:headphones=constant audiofocus:speakers=none userinput=rare network=constant } |
A functional spec for the PPM is hosted on the project home page: http://www.lesswatts.org/projects/power-policy/ |
| Line 237: | Line 105: |
| usagemode VIDEO-LOCAL { appfocus=realplayer videofocus=constant audiofocus:headphones=constant audiofocus:speakers=none userinput=rare network=none } |
Testing will focus on three main functional areas:[[BR]] |
| Line 246: | Line 107: |
| usagemode VIDEO-STREAM { appfocus=realplayer,vlc,winamp videofocus=constant audiofocus:headphones=constant audiofocus:speakers=none userinput=rare network=constant } |
* DBus based application interface for activating/deactivating layers * PPM Plug-in interface for inserting new micro-policy engines * Core PPM engine parsing of policy files |
| Line 255: | Line 111: |
| usagemode WEBSURF { appfocus=firefox,seamonkey,netscape videofocus=constant audiofocus:headphones=none audiofocus:speakers=none userinput=intermittent network=intermittent } |
Testing will not explicitly cover individual device policies, but device specific policy files will be created and exercised for a handful of devices in order to meet the functional testing goals stated above.[[BR]] |
| Line 264: | Line 113: |
| usagemode PRESENTATION { appfocus=openoffice,picviewer videofocus=constant audiofocus:headphones=none audiofocus:speakers=none userinput=intermittent network=none } }}} |
NOTE: It is the device vendor / solution creator that will need to craft device specific policy and potentially PPM plug-ins. Since the PPM is general purpose, it is impossible to test for the infinite number of devices that might hit the market. [[BR]] |
| Line 274: | Line 115: |
| === Location Modes === | == Outstanding Issues == |
| Line 276: | Line 117: |
| The location mode will capture where the device is, how it's moving, and what restrictions there are on the device. These can be editted manually by a user but will require a daemon restart for them to be recognized. Some examples are as follows: | This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. |
| Line 278: | Line 119: |
| {{{ locationmode AIRPLANE { radios=forceoff outletpower=plane tgtbattlife=4hour ambientlight=officelight movement=plane } |
A standard mechanism for measuring system power utilization needs to be adopted before an optimal power policy can be created. The lesswatts project is working towards this goal. |
| Line 287: | Line 121: |
| locationmode CAR { radios=forceoff outletpower=car tgtbattlife=8hour ambientlight=daylight movement=car } |
== BoF agenda and discussion == |
| Line 295: | Line 123: |
| locationmode CONFERENCEROOM { radios=allowon outletpower=ac tgtbattlife=1hour ambientlight=officelight movement=still } |
N/A |
| Line 303: | Line 125: |
| locationmode WALKING { radios=allowon outletpower=solar tgtbattlife=2hour ambientlight=sunlight movement=walking } }}} |
---- CategorySpec |
| Line 312: | Line 128: |
| = PPM Daemon = |
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: PowerPolicyManagement
Packages affected: ppm
Summary
The Power Policy Manager (PPM) is a layered, system-wide power policy framework. Most power managers assume a binary power policy. For example, they change power policies when AC power is removed, but don’t provide a way for users to override these settings. Many policy managers that do provide user choice attempt to hardcode exceptions, and do not provide a way for users to select multiple power policies.BR
This functional specification proposes the addition of PPM package into the UME apt repository to solve the Mobile-Internet-Device specific power policy needs.BR
Release Note
By adding the ppm implementation, a new mechanism for defining device power profiles will be added to the UME technology pool. For the most part the operations of the PPM will be seen by the end user, but eventually new control panel applets and/or status bar indicators could provide additional controls and/or information about the device power state.
A classic example would be a control panel applet that would provide a UI for placing the device into "Airplane Mode", which would trigger the device to turn off all radios (per federal air regulations) and also enable various low level power saving settings to enable the end-user to use their device for as long as possible.
Rationale
What is needed is a flexible power policy manager that allows users to select multiple policies, and easily modify those policies to fit their system. The system should leverage existing system power management capabilities, such as Advanced Configuration and Power Interface (ACPI). It should also allow users to write their own power management code for new hardware. Most importantly, it should be a system-wide policy manager that focuses on more than just the CPU frequency.BR
Use Cases
Assumptions
- Device provides some mechanism for regulating power hungry devices. This could be something as common as ACPI, or as unique as a custom micro-controller with a ad-hoc interface for programing from the Linux system running on the CPU.
Design
The Framework The PPM breaks down power policy management by using plug-ins, layers, and modes.
- Modes determines which layers to use.
- Layers contains the list of commands.
- Plug-ins communicate the commands to the hardware.
BR A mode contains the list of which layers to activate. Multiple modes can be active at the same time. If two modes select different layers, the commands sent to the plug-ins will be based on a combination of the layers. Higher priority layers take precedence. BR For example, if one layer had the plug-in command, "cpu performance max", but a higher priority layer had the plug-in command, "cpu performance cool", the latter command would be sent to the cpu plug-in. Layers are transparent, which means that commands from lower priority layers that don�t overlap with commands from higher priority layers, are active. BR A policy layer is a grouping of plug-in commands, with an associated priority. BR Example layer 1 For example, a low-power layer might contain commands to:
- set the CPU to a low-power mode
- set the screensaver timeout to 2 minutes
- dim the screen
BR Example layer 2 A second layer, dealing with thermal issues, might:
- set the screensaver timeout to 30 seconds
- put the SATA hard drive into low power mode
- tell the CPU to go into "cool" mode
BR Which layer takes precedence? The thermal policy layer would have the highest priority, to make sure that the system doesn't overheat. BR Code example A layer file would look something like this (first release is simple text description):
- File name convention: Priority_Name (for example: 00_default)
- Policy file structure is three columns and N number of rows.
- First column is CLASS, referring to device classes.
- Second column is COMMAND, referring to operation to be invoked on the device or subsystem.
- Third column is VALUE, such as ON, OFF, MAX (depending on the device).
BR Layer content An example of the 00_default policy:
CPU Performance Max radio radio allowed wifi radio on display screensaver user display brightness 50 bt radio off
Implementation
The source tree for the ppm is available in a public git tree via: http://www.lesswatts.org/repos/projects/ppm.git/
The implementation is split into:
- daemon: PPM service launched at system startup
- ppmtool: command line tool for configuring the ppm deamon
- plugins: PPM plug-ins that receive power policy commands and then interpret those commands to specific actions
- layers: power policy configuration files
- modes: configuration files that group sets of layers together
UI Changes
The PPM package does not present a UI, but as soon as the PPM is available in UME then a moblin-applets control panel applet will be added that allows the user to set airplane mode.
Code Changes
This is all new code.
Migration
N/A since this is all new code.
Test/Demo Plan
A functional spec for the PPM is hosted on the project home page: http://www.lesswatts.org/projects/power-policy/
Testing will focus on three main functional areas:BR
- DBus based application interface for activating/deactivating layers
- PPM Plug-in interface for inserting new micro-policy engines
- Core PPM engine parsing of policy files
Testing will not explicitly cover individual device policies, but device specific policy files will be created and exercised for a handful of devices in order to meet the functional testing goals stated above.BR
NOTE: It is the device vendor / solution creator that will need to craft device specific policy and potentially PPM plug-ins. Since the PPM is general purpose, it is impossible to test for the infinite number of devices that might hit the market. BR
Outstanding Issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
A standard mechanism for measuring system power utilization needs to be adopted before an optimal power policy can be created. The lesswatts project is working towards this goal.
BoF agenda and discussion
N/A
MobileAndEmbedded/PowerPolicyManagement (last edited 2008-08-06 16:26:39 by localhost)