According to one industry analyst, Linux has made great strides in the "smartphone" arena, the top tier of handsets, with multi-million unit deployments from multiple vendors. With its enterprise and workstation pedigree, Linux is suited for high-end phone deployments due to its performance, robustness, security, and networking. However, high-end smartphones also place the most challenging demands on handset energy budgets. Larger touchpad displays, multimedia capabilities, dedicated WAN modem chips, Bluetooth and Wi-Fi network interfaces, and more RAM and flash for downloadable applications create a higher hardware bill-of-materials (BOM) and draw more power.

The challenge for Linux in mobile applications, then, is to break out of the high-end, high-functionality box to reach higher-volume mid-tier and perhaps even entry-level devices. Handset makers and mobile chipset vendors understand that power and energy management are key for Linux to continue its expansion in the handset market.

Notebook owners with a modicum of curiosity quickly notice that their portable devices behave differently when running on battery verses ac power: the screen dims, the processor clock slows, and the system spins down to standby or drifts off sleep whenever possible. Handheld device owners also contend with screens dimming and devices sleeping after a quiescent period, and cell-phone users grow accustomed to backlights and key-lights extinguishing themselves once a call is dialed. Behind these visible behaviors common to mobile devices are a mix of hardware and software technology and policy.

Device energy budget
Anyone who's ever burned a finger on a hot CPU chip knows that high-speed silicon can dissipate a lot of power. Gigahertz-plus system clocks place desktop machines in the same power-hungry class as incandescent bulbs and home appliances.

That's not the case with mobile handsets. Today's high-end mobile devices sport modest CPU specs, with clocks in the 200- to 500-MHz range; voice-only handsets can run at 40 MHz or below. As such, mobile CPUs consume a quarter or less of the total energy budget, with the display and backlight eating up the lion's share (Fig. 1). The result is that an effective power optimization scheme, in Linux as in competing OSs, must encompass an array of sub-systems beyond the CPU.

Energy-management techniques and technologies Handheld energy management relies on a mix of capabilities in silicon and software, including clock frequency, operating voltage, device power-down, and more MIPS/W. The most common optimization for energy conservation in all types of mobile applications is clock scaling. Indeed, most mobile devices run at a default CPU clock rate well below the available performance peak for the chip. Whereas notebook use policy usually dictates throttling back the CPU clock when the system is idle, handheld/mobile devices only rev up the clock when applications or I/O events need extra throughput.

Traditional silicon design techniques made it difficult or impossible to vary operating voltage during system operation, or even in system designs. As such, most legacy power-management techniques focus on clock speed and gross (on/off) peripheral device conservation. Scaling back voltage, however, offers much greater energy savings. Whereas returns on clock scaling are more or less linear, voltage scaling can yield exponential energy savings with a higher impact on battery life. Modern mobile CPUs like Intel's XScale and TI's OMAP feature a wide range of operating voltages in the CPU core and across their on-chip peripherals as a means to conserve energy.

In quiescent states, and when users elect to power down their mobile devices (standby), even greater energy savings exist. Even without user intervention, however, system software can selectively "turn out the lights" on a range of on-board devices, with concomitant energy conservation.

For compute-hungry applications, like games, voice recognition, and some enterprise client software, recent advances in CPU design let designers provide more compute power without raising energy-hungry system clocks. Just as with modern servers, and increasingly with high-performance desktops, multi-core processors will find their way into handsets. Early last year, ARM demonstrated dual- and quad-CPU versions of the ARM11 architecture, with real-world deployments expected to begin later this year.

Energy-management opportunities
Combining the realities of actual power budgets with optimization techniques leads handset designers to view each component and subsystem of these compact embedded computers in terms of the opportunities they present for conserving power. For example, as with the "applications processor" that runs Linux or another OS, on-chip DSPs and multimedia CODECs can be power-managed through clock and frequency scaling. Beyond CPU cores, savings can be squeezed from both volatile and persistent memory by modifying bus clocks, refresh rates, and access modes; further savings are possible by powering off or scaling back performance on buses and devices across the system.

Linux energy-management toolbox
Over the last decade, members of the open source community, Linux distributors and tools suppliers, and software teams at key semiconductor suppliers have invested substantial resources in implementing and enhancing the energy-management capabilities of the open source GNU/Linux OS. Indeed, because of the open nature of the Linux code base, the OS represents a global laboratory for experimentation and innovation in power savings technology.

Embedded device OEMs often start their research by looking to the desktop, where notebook-centric schemes like ACPI and APM dominate, and indeed occupy most discussions of Linux power management on the kernel mailing list (www.kml.com). For non-x86/IA-32 notebook hardware, OEMs can turn to PMU for Apple PowerPC hardware (see the table). Embedded OEMs deploying ARM-licensed silicon can leverage the ARM IEM framework, or work with the various power-management schemes present on silicon from dozens of ARM licensees (such as Freescale, Intel, NEC, Samsung, and TI). There also exist unique and further divergent energy conservation protocols from MIPS and MIPS licensees, from Freescale for its CPU lines, from IBM for Power Architecture, from Renesas and Hitachi, and so on across the silicon supplier universe. OEMs can also choose software platform schemes like MontaVista's DPM and other embedded Linux supplier solutions.

Dynamic management
While desktop/notebook schemes like APM and ACPI are more ubiquitous, ARM IEM and MontaVista Software DPM present the greatest promise for energy-management returns on handheld investment. Indeed, most of the global and regional mobile device makers building phones today with Linux employ IEM, DPM, or a comparable in-house schema.

The defining characteristic of dynamic management lies in aggressive, high-frequency changes to the operating state. Unlike legacy power-management schemes, which vary operating state in hundreds of milliseconds or even multiple seconds, dynamic schemes enable devices to change operating state at rates limited only by the time needed to change the power supply voltage or the time to vary the CPU clock.

An interesting illustration of the ambitious nature of dynamic schemes is saving energy between frames of streaming or locally stored video (Fig. 2). High-quality video runs at 24 frames/s, leaving 41.66 ms between frames for rendering the next frame and other activities. Even on low-power CPU cores running at 40- to 60-MHz, 41.66 ms represents a "long time" and presents ample opportunities for power management.

Once a video frame has been presented to the user, the system proceeds as follows:

• The CPU initiates retrieval of the next compressed frame from either local storage or from streaming file buffers. This is a low CPU activity due to on-board DMA engines.
• The compressed image is transferred (via DMA or shared memory) to a codec (DSP or other dedicated hardware) for decompression/rendering. This is a medium CPU, high codec activity.
• When the image is decompressed, the CPU invokes the video interface driver, a high CPU and ultimately high display utilization.
• During image processing, the display backlight draws energy. Factoring in persistence of human vision or gamma adjustment to the image itself, this parameter may also be reduced to a more moderate consumption level.

Dynamic-management architecture
With embedded Linux (as with other energy-managed OSs and applications), dynamic energy-management activities predicate involvement at many levels of the software stack. Low-level implementation of dynamic management is resident in the Linux kernel for both ARM IEM and for DPM. However, management policies may originate in middleware and user application code.

Ideally, an energy management system would be transparent at most or all levels of the software stack, Such transparency dictated the path followed by Transmeta in its Crusoe architecture and has been the goal of existing BIOS-based power-management schemes. However, for deep gains in battery life, some explicit participation is required across the system. Visible participation also independent software vendors (ISVs) such as game suppliers opportunities to add value and differentiate.

In MontaVista DPM, a kernel subsystem maintains the system's power state and ties together power-managed elements. The DPM subsystem communicates directly with device drivers using APIs that move the drivers from full operation into various power-managed states. A policy manager (or the applications themselves) provides guidance to the DPM subsystem through APIs that define policy and move the system among defined operating states.

DPM-enabled device drivers are more "stateful" than familiar stateless drivers. External events and callbacks from the DPM subsystem drive device interfaces through states that reflect/follow operational policies. Kernel APIs also allow device drivers to register the devices' basic operational characteristic they interface/manage, allowing for finer-grained policy decisions.

In schemes like DPM, three approaches exist for writing new applications or porting existing ones. First, management-aware applications can use APIs presented by a policy manager to register base operating parameters and/or drive power-management policy changes to match execution requirements. Second, legacy applications without explicit energy management can be "wrapped" in code and/or patched to attain the same behavior found in natively enabled programs. Third, legacy applications can run with default behaviors, and look to system-wide default policies.

Developing and deploying energy management
Dynamic energy and power management for Linux is still evolving. ARM and its licensees are now striking a balance between standardizing on common ARM silicon while leaving room for each to add value with unique implementation features. MontaVista Software, through its own efforts and through the auspices of CELF and OSDL, sees its DPM being adopted in embedded apps, but DRM and IEM both represent divergent paths from enterprise-centric desktop and server schemes that dominate the mainstream Linux kernel tree. In addition to these logistical hurdles around acceptance and standardization, distinct technical gaps must be crossed, such as energy-management latency.

Voltage- and frequency-scaling latency
Aggressive dynamic energy-saving paradigms require that system hardware respond at least as quickly as policy-directed changes in operating state changes. If a dynamic power system must transition from one operating point to another, clocks and power supplies must be able to accompany those changes in application-specific timescales.

Time to vary voltage must be less than the time between operating states. To implement the video frame optimizations described earlier, the time to vary voltage must be in the 5-ms range (200 Hz). However, when dynamic schemes first appeared in Linux in 2003, power supplies on standard evaluation boards could only deliver voltage changes under load in around 200 ms (5 Hz). The software worked properly, but the available hardware couldn't keep up. In the intervening time, silicon suppliers have designed better power supplies to support design-in of dynamic energy management and other capabilities.

If mobile device adoption of Linux continues at its present pace, volume markets like Japan and China will deploy Linux on one phone in eight by the end of 2006—almost 20 million handsets. Ideally, device users needn't know nor care about the underlying OS in their handsets. Aftermarket software supplied by carriers and operators, however, is highlighting choice of OS for device makers, integrators, and original design manufacturers (ODMs). This newfound visibility is creating platform brand awareness where none existed before. While branding has always been a key focus Linux competitors, penetration into high-volume markets represents a great opportunity for the open source OS.

About the author
Bill Weinberg, a founding member at MontaVista Software, is a strategist/analyst at the Open Source Development Labs, where he participates in OSDL initiatives for carrier-grade, data-center, and desktop Linux. He can be reached at bweinberg@osdl.org.