Power Management

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. 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.

Architecture 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)

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.

Constraints

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

No dependence on knowledge of specific applications or drivers
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 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.vers
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)

Table 2.1. Energy Focus

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 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

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 connectionDevice movement
- Plugged in (ACPI Event)
  - AC wall socket
  - DC Car jack
  - DC Aeroplane jack
  - DC Solar Charger
  - External Battery
- X minutes until power source/wifi available (ETA)
  - immediately (e.g. in a car, at home, airport terminal)
  - less than 20 (e.g. in transit between home and work)
  - less than 120 (e.g. general mobile usage)
  - less than 240 (e.g. a standard plane ride in coach)
  - less than 480 (e.g. a standard college school day)
  - very large (e.g. on a camping trip)
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


Mobile Graphics		Power Thermal Optimizations