To differentiate products in a crowded and competitive marketplace, manufacturers of handheld devices highlight battery life and power management as key selling points for their wares - cellphones, PDAs, multimedia players, games and other portable consumer devices. While users perceive results of power management in terms of battery life, it is really a combination of CPU capabilities, system software, middleware and policy that allows users to enjoy their gadgets for more time between charges or battery changes.

This article offers insight into the interaction among these elements. In particular, it focuses on trends around embedded Linux and the dynamic power management (DPM) architectures being specified and soon deployed by MontaVista Software, IBM, TI, Intel and others, including members of consortia like the Consumer Electronics Linux Forum.

Power management scope
Anyone who owns a notebook computer will perceive that their portable device behaves differently when running on battery vs. on AC main power - the screen dims, the processor clock slows and the system drifts off to standby or to sleep whenever possible. PDA owners will also contend with screens dimming and devices sleeping after a quiescent period, and cellphone users will have noted that after dialing, backlight and key-lights extinguish. Behind these visible behaviors are a mix of hardware and software technology and policy.

Gross behaviors like full throttle, standby and sleep leverage native CPU capabilities to reduce operational voltage and/or clock frequency to save power. What most device users do not perceive is that rather than just wholesale changes among system-wide states, actual power management can also be incremental and can occur hundreds of times a second.

Any DPM strategy begins with scaling the operating voltage and frequency of one or more processor cores present in a portable device - high integration PowerPC, ARM and x86-based systems often feature a DSP or intelligent base band processor. Indeed, CPUs such as the Intel StrongARM and XScale, TI OMAP processor family, the recently announced IBM PowerPC 405LP and the Transmeta Crusoe, offer dynamic scaling of core voltage and frequency.

Modern embedded processors are so power-efficient that the CPU is not always the major energy-consumer - other energy hogs can include high-performance memories, color displays and radio interfaces. Therefore, a dynamic power management system that is only concerned with core voltage and frequency scaling the processor core may be of limited use.

A truly useful dynamic power management scheme will support rapid scaling of a variety of voltages and clocks, in concert with or independently of the CPU core operation.

Architecture
Coming from the universe of "white box" PCs and notebooks are two existing schemes for power management: the legacy advanced power management scheme and advanced configuration power interface (ACPI). Systems like ACPI are preferred for commercial off-the-shelf hardware like PCs, notebooks, servers and blades for communications equipment, but present strong dependencies on the prevailing x86/IA-32 BIOS architecture.

Embedded systems usually have no BIOS (in the PC/AT sense) and typically do not have the luxury of machine abstractions to insulate the OS from low-level device and power management activities. In embedded Linux, as in other OS that target battery-powered applications, power management activities require specific intervention on the part of the OS kernel and device drivers. It is important to note, however, that while low-level implementation of dynamic power management is resident in the OS kernel, power management strategies and policies can emanate from middleware and user-application code.

Ideally, a power management system would be almost completely transparent to as many levels of the software stack as possible. Indeed, this was the path followed by Transmeta in its Crusoe architecture and has been the goal of existing BIOS-based power management schemes. However, developers with experience in building handheld devices will testify to the fact that some degree of explicit participation is required across the system, as follows:

Kernel interfaces: In the DPM architecture for Linux, the DPM subsystem within the kernel maintains the power state of the system and ties together the various power-managed elements of a DPM system. Relatively few, if any, other parts of the kernel need to interact with the DPM directly. DPM is best thought of as a service provider to drivers, middleware and applications.

Driver interfaces: DPM-enabled device drivers are more "stateful" than default drivers. They are driven through various states by external events and through callbacks from the kernel DPM subsystem to reflect/follow operational policies. Driver APIs also allow drivers to register the basic operational characteristic of the devices they interface/manage for finer-grained policy decisions.

User-program APIs: User programs (applications) will fall into one of three categories: · Power management aware;
· Legacy applications in power management-aware wrappers;
· Legacy applications with no power management.

Power-management aware applications can leverage the APIs available from a policy manager to establish their base constraints and/or to force changes in power management policy to match their execution requirements. Legacy applications without explicit power management capabilities can be "wrapped" in code and/or patch to achieve comparable effects, but can also be left to run with default behaviors, dependent upon default policy management of a wider scope.

Real-time impact
Until recently, scaling CPU voltage and frequency presented significant challenges to real-time performance. The instability introduced by changes in either parameter and the accompanying time needed to "relock" PLLs and other dynamic clock mechanisms, introduced long latencies (sometimes many milliseconds) during which the CPU could neither perform compute operations nor respond to outside events (interrupts).

Modern embedded processors can scale frequencies with latencies measured in a handful of microseconds, and respond to changing voltages with a latency measured in tens of microseconds, all without interrupting system operations, allowing for more aggressive and fine-grained policies. For example, voltage and frequency can be reduced between frames of MPEG video or IP-based voice packets.

A more general challenge to real-time performance is that of response to interrupts during sleep modes. While most on-chip peripherals may be programmed to "wake up" the system upon receipt of an interrupt, developers must carefully specify policies to enable (selective) device-based wake-up and account for system-wide latencies and storage classes to ensure timely execution of interrupt handlers and/or user-space responses to events (preemption latency).

Ideally, device users do not need to know the underlying OS in their handheld purchases. However, the availability of carrier-supplied and after-market software is giving device manufacturers' choice of OS more visibility and creating brand presence where none existed. While branding has always been a key focus of Microsoft's penetration into service delivery markets (like cellphones) with volumes far in excess of PDAs, it lags behind Symbian, Brew and embedded Linux.

One of the reasons why device builders are turning to Linux is the opportunity to leverage standards-based power management instead of the proprietary status quo, to achieve faster time-to-market and to meet end-user and carrier technology requirements.