Introduction

In designing a Linux-based software stack for the Mobile & Internet Linux Project, power management was a fundamental problem. The definition of the problem was simple. This new class of devices is much closer, at the low level, to a PC than to an embedded device. The hardware already has power management capabilities similar to those found on a PC, laptop, and even a server. Technologies, such as ACPI, are a fundamental component of most modern PC hardware, and to the new class of devices we are trying to support.

The second consideration was our use of a general purpose Linux distribution for x86 Intel Architecture platforms, rather than an embedded Linux or special purpose distro.

Keeping these two concepts in mind, we went through the exercise of evaluating the current state of Linux's power management infrastructure. We quickly realized that there is a lot of work already in place addressing power and Linux, but this work is fragmented. There are HAL and D-Bus-based solutions, which have basic functionality; but there are also advanced CPU power management and power management 'aware' drivers and subsystems.

Most of the work is done in the kernel or device drivers, so we decided to pursue a solution that would fill in the gaps, so Linux would have a comprehensive, robust, and extensible power management framework.

Power Policy Manager (PPM): A Reality
The idea of having a policy-based power management framework in Linux is nothing new (so we won't try to take credit for it!) However, we are a team of engineers committed and empowered to make sure such a framework is implemented and supported. The initial motivation is the new class of mobile and Internet devices, however, we want to implement a generic, flexible, and extensible power management framework for Linux, in general. Being extensible will mean that it can easily be optimized for different platforms.

How does it work?

How many of us travel with a laptop running some Linux distribution and discover that while there is no wireless access on the plane, the WIFI device is active and turning it off is a manual process? Or, the Ethernet port is always on, though nothing is plugged in it, and all of the audio device codecs are enabled, but are not used. Then there are all those processes running, which last time I checked are almost never used on a plane, yet they *might* be preventing the CPU from reaching power saving deep sleep or idle states. PPM attempts to solve this and similar problems with its Macro and Micro Policy Engines.

PPM consists of four main components:

1. policy definition files
2. policy and layer parser & interpreter (that is, Macro Policy Engine)
3. Micro Policy Engine
4. D-Bus service

A policy 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.
• 1st column is CLASS, referring to device classes.
• 2nd column is COMMAND, referring to operation to be invoked on the device or subsystem.
• 3rd column is VALUE, such as ON, OFF, MAX (depending on the device).

An example of the 00_default policy:

cpu	performance	max
radio	radio	allowed
wifi	radio	on
lcd	screensaver	user
lcd	brightness	50
bt	radio	off
audio	speakers	on
audio	microphone	off

Policy 00_xxx is default and is loaded at boot. Subsequently, other policies could be requested such as 11_acpower which does not replace 00_default; rather it needs to be layered on top of it, and only the delta is executed. For example, if the system is in 10_battery policy, then aggressive battery savings, such as screen brightness and sleep values, are used. However, the user (or system/application) indicates a change in operating mode, such as presentation full screen mode, which results in disabling the screensaver. The new policy for the system is a layered state in which aggressive power saving is still preferred, yet accommodates the presentation application's needs. You can imagine numerous cases which could leverage the power of this approach. The PPM has a policy layering infrastructure allowing just that.

In addition, we have the Micro Policy Engine, which is responsible for executing the policy and relaying messages to the impacted devices and/or subsystems, to change state or operating point. The Micro Policy Engine is a pluggable model which, at runtime, loads all available Micro Policy Engines, and sends messages to all registered plug-ins of desired actions.

Micro Policy Engines are shared libraries that have two basic functions:

1. Export a message interface
2. Manipulate the device's and/or subsystem's power interfaces.

It's important to note and understand that the Micro Policy Engine is an msg broadcast interface. It doesn't have knowledge of each plug-in's 'specialty.' Rather, it broadcasts the same message to each registered plug-in and the impacted or relevant plug-in will intercept the message and react accordingly.

Finally, PPM is a D-Bus system service which monitors and receives its directives over D-Bus. Further, applications that are power-aware can msg PPM over D-Bus of requested actions, hints, or specific policies. In general, the main interface to PPM will be D-Bus. We will provide the ability to query PPM for current active policies, message a request to change current policy, and then layer the current active policies.

Architecture Diagram (click for larger image)

In Closing

The strength of the PPM approach is simplicity in code-- making it compact, lightweight, and modular. We wanted to allow developers, with intimate knowledge of devices and subsystems, to innovate and contribute complex plug-ins, which expose maximized power-savings features. We didn't want developers to worry about the details of the framework and what sometimes could be considered a routine code or even a distraction. Having said that, we encourage and invite developers to contribute to all aspects of the PPM and write, enhance, or optimize plug-ins.

The success of the PPM is measured by its acceptance into the Linux and Open Source Community. We want to hear your feedback and get your help in making this crucial component a successful power management solution for Linux.