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.

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

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

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

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)

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

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.

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

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

• 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

Configuration Element Groups

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

Usage Modes

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:

usagemode MUSIC-LOCAL {
        appfocus=realplayer 
        videofocus=none 
        audiofocus:headphones=constant
        audiofocus:speakers=none
        userinput=rare
        network=none
}

usagemode MUSIC-STREAM {
        appfocus=realplayer 
        videofocus=none 
        audiofocus:headphones=constant
        audiofocus:speakers=none
        userinput=rare
        network=none
}

usagemode VIDEO-LOCAL {
        appfocus=realplayer 
        videofocus=none 
        audiofocus:headphones=constant
        audiofocus:speakers=none
        userinput=rare
        network=none
}

usagemode VIDEO-STREAM {
        appfocus=realplayer,vlc,winamp
        videofocus=none 
        audiofocus:headphones=constant
        audiofocus:speakers=none
        userinput=rare
        network=none
}

usagemode WEBSURF {
        appfocus=firefox,seamonkey,netscape
        videofocus=none 
        audiofocus:headphones=constant
        audiofocus:speakers=none
        userinput=rare
        network=none
}

usagemode PRESENTATION {
        appfocus=openoffice,picviewer
        videofocus=none 
        audiofocus:headphones=constant
        audiofocus:speakers=none
        userinput=rare
        network=none
}

Location Modes

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:

locationmode AIRPLANE {
        radios=forceoff
        outletpower=plane
        tgtbattlife=4hour
        ambientlight=daylight
        movement=plane
}

locationmode CAR {
        radios=forceoff
        outletpower=car
        tgtbattlife=8hour
        ambientlight=daylight
        movement=car
}

locationmode CONFERENCEROOM {
        radios=allowon
        outletpower=ac
        tgtbattlife=1hour
        ambientlight=daylight
        movement=still
}

locationmode WALKING {
        radios=allowon
        outletpower=solar
        tgtbattlife=2hour
        ambientlight=daylight
        movement=walking
}

PPM Daemon