Dynamic power management based on Linux: making embedded devices more energy-efficient

zbz0529

Dynamic power management based on Linux: making embedded devices more energy-efficient [Copy link]

To differentiate their products in a crowded and competitive market, manufacturers of handheld devices often consider battery life and power management as key selling points for cell phones, PDAs, multimedia players, game consoles, and other portable consumer devices. Users view power management effectiveness in terms of battery life, but it is actually the result of a combination of factors, including CPU capabilities, system software, middleware, and strategies that allow users to enjoy their devices longer between recharges or battery replacements. The Scope of Power
　　Management
　　Anyone who has a laptop computer will have noticed that their portable device behaves differently when running on battery power than when running on AC (mains power), with the screen dimming, the processor clock slowing, and the system going into standby or sleep mode whenever possible.
　　In addition, PDA owners have noticed that the screen dims and the device even goes to sleep after a period of inactivity, while cell phone users have noticed that the backlight and key illumination go out after dialing a number. Behind these behaviors that are visible to the naked eye are a number of hardware and software technologies and strategies.

Obvious behaviors such as full-speed operation, standby, and sleep take advantage of the CPU's inherent ability to reduce operating voltage and/or clock frequency to save power. Unnoticeable to most device users, actual power management can also be incremental and occur hundreds of times per second, rather than large-scale changes in the entire system state.
　　Any dynamic power management (DPM) strategy begins with adjusting the operating voltage and frequency of one or more processor cores present in a portable device - highly integrated, PowerPC, ARM, and x86-based systems often have a DSP or intelligent baseband processor. In fact, processor families such as Intel XScale and TI OMAP provide dynamic adjustment of core voltage and frequency. However, modern embedded processors are so power efficient that the CPU is not always the primary energy consumer; other large energy consumers may include high-performance memory, color displays, and wireless interfaces. Therefore, a dynamic power management system may be of limited use if it focuses only on adjusting the voltage and frequency of the processor core. A
　　truly useful power management scheme will support rapid adjustment of various voltages and clocks, either in conjunction with the operation of the CPU core or independently.
　　Architecture
　　Two existing power management schemes come from the world of "white box" PCs and laptops. The first is the traditional "Advanced Power Management " (APM) scheme, which is still used in many Linux-based portable devices, but has been discontinued in laptops and handheld devices based on Microsoft operating systems. The second is the "Advanced Configuration and Power Interface" (ACPI), the current standard supported by Intel, Toshiba and others. For "commercial off-the-shelf" (COTS) hardware such as PCs, laptops, servers, and even blade servers for communication equipment, systems such as ACPI are more popular, but they show a strong dependence on the current x86/IA-32 BIOS architecture.
Embedded systems usually do not have a BIOS (in the PC/AT sense), and usually do not have the luxury of machine abstractions to isolate the operating system from low-level device and power management activities. Therefore, in embedded Linux, as in other operating systems for battery-powered applications, power management activities require special intervention in the operating system kernel and device drivers. One important thing to note, however, is that while the low-level implementation of dynamic power management resides in the operating system kernel, power management strategies and policies can and do originate from middleware and user application software code.
　　Interfaces and APIs
　　Ideally, the power management system would be almost completely transparent to as many layers of the software stack as possible. In fact, this is the route that Transmeta has taken in its Crusoe architecture, and has been the goal of various existing BIOS-based power management schemes. However, developers with experience in building handheld devices will attest to the fact that all parts of the entire system require some degree of direct involvement, as described below:
　　Kernel Interfaces In the DPM architecture for Linux, the DPM subsystem in the kernel is responsible for maintaining the power state of the system and tying together the various power-managed elements of the DPM system. The DPM subsystem communicates directly with device drivers through multiple APIs that transition drivers from fully operational states to various power-managed states. The policy manager (or the application software itself) provides guidance to the DPM subsystem through multiple APIs that define various policies and move the entire system between defined operating points.
　　Driver InterfacesDPM-enabled device drivers are more "stateful" than default drivers: they are driven through various states by external events or by callbacks from the kernel's DPM subsystem, reflecting and following operational policies. The driver API also allows drivers to register basic operational characteristics of each device they connect to and manage, enabling more granular policy decisions.User
　　Program APIsUser programs (applications) fall into three categories: · Power
　　-aware applications 　　· Traditional applications in power-aware "wrappers" · Traditional applications 　　without power managementPower - 　　aware applications can take advantage of the APIs from the policy manager to establish their own basic constraints and force changes in power management policies to match their execution requirements.Traditional applications without direct power management capabilities can be "wrapped" in code or patches to achieve equivalent results, or they can run with default behavior, subject to wider default policy management.



　　The actual mechanisms under the embedded Linux DPM include APIs such as dpm_set_os() (kernel), assert_constraint(), remove_constraint(), and set_operating_state() (kernel and drivers), set_policy() and set_task_state() (user-level interfaces via system calls), and /proc interfaces.
　　Saving Power with DPM
　　Unique Power Saving Opportunities
　　The defining characteristic of DPM is the rapid, high-frequency nature of power management . Unlike the traditional desktop/laptop paradigm, which operates in hundreds of milliseconds or seconds, DPM enables the management of each device to be limited only by the time required to change the supply voltage (T芕) or the CPU clock (T芕).
　　Saving power between frames of streaming video is best illustrated by this property of DPM. High-quality streaming video runs at 24 frames per second, leaving 41.66 milliseconds of available time between frames for rendering the next frame and other activities. Even on a low-power CPU core running at 40-60MHz, 41.66ms represents a “long time” and presents ample opportunity for power management
. 　　After a frame of video is presented to the user, activity proceeds as follows:
　　The CPU requests/fetches the next frame of compressed video, either from the local storage system or from a streaming file buffer – low CPU activity The
　　compressed image is transferred (via DMA or shared memory) to the codec (DSP or other dedicated hardware) for decompression/rendering – moderate CPU activity, high codec activity
　　When the image is ready, i.e. decompressed, the CPU calls the video interface driver – high CPU utilization and ultimately high display utilization
　　Throughout the image processing, the display backlight consumes energy. This parameter can also be reduced to a more modest consumption level by taking advantage of persistence of vision or gamma adjustment on the image itself.
Summarizing the energy requirements during each stage of video frame processing results in the waveform shown in Figure 2, with the area “above the line” representing potential energy savings.
　　Benefits of Clock Frequency Scaling vs. Voltage ScalingCPU
　　clock frequency scaling is a common way to save power in embedded devices. At a given voltage, a higher clock speed requires more power to push the logic level to saturation (overcome capacitance) than a lower clock speed. Also, clock frequency scaling is relatively easy to implement, at least within the CPU core. However, the benefits of voltage scaling are much greater—power consumption is proportional to clock frequency, and almost the cube of system voltage!

DPM itself makes no assumptions about the relationship between clock frequency and voltage. In theory, both parameters can be varied independently and continuously.
　　In practice, at a given clock frequency, there is a minimum feasible voltage (the minimum supply voltage)—lower voltages will not push the logic level to saturation within the required cycle time, and higher voltages will simply consume more power. To simplify the power management algorithm, schemes such as DPM do not attempt to continuously vary the clock and voltage. Instead, the designer selects a series of reasonable operating points on the clock/voltage continuum, and DPM drives the CPU and other power-managed system components point by point. Challenges in
　　Developing and Deploying Power ManagementDPM
　　for embedded Linux is an evolving technology. Its core technology is improving thanks to contributions from developers in the global open source community, but practical applications still have to clear a number of "roadblocks."
　　Coordinating DPM CPU clocks and voltages across all device subsystems
　　introduces a very flexible set of power management parameters that target one of the main power consuming devices in the device. Other devices (backlight, RF, etc.) also present power management opportunities, but can result in very different types and numbers of operating points. However, it is rare for the various nodes in a system to be completely independent. The CPU connects to buses, bridges, memory, and directly to other peripherals, and changing the clock and voltage of one device may limit its electrical and logical connections to neighboring devices. Options for resolving such incompatibilities include:
　　Grouping CPU cores and peripherals into blocks that share operating point characteristics Selecting operating point clock rates that are multiples of each other 　　Using voltage translators/buffers or open collector circuits to reduce voltage differences Overcoming voltage and frequency adjustment latency
In order to support an aggressive power-saving paradigm such as DPM, the system hardware must be able to respond at least as fast as 　　the state 　　changes directed by the DPM policy occur. That is, if a DPM system needs to transition from one operating point to another within a given time, the power circuitry must be clocked to occur with these changes. 　　In other words, the time it takes to change voltage 　　must be less than the transition time between operating points ( T芕 < T芆P ). To achieve the inter-frame scheme described above, T芕 must be in the 5 millisecond range (200 Hz). Some DC-to-DC power supplies run at about 200 Hz internally and can only deliver voltage changes within about 200 milliseconds (5 Hz) under load, reducing the usable resolution and utility of DPM-based systems. Real-time Impact　　Until recently, CPU voltage and frequency scaling presented significant challenges to real-time performance. Changes in either parameter created instabilities, and the time required to "relock" phase-locked loops and other dynamic clocking mechanisms resulted in long wait times (sometimes many milliseconds) during which the CPU could neither perform computational operations nor respond to external events (interrupts). Advanced embedded processors such as TI OMAP and Intel XScale can adjust frequency with latencies in the microseconds and respond to voltage changes with latencies in the tens of microseconds without interrupting system operation, allowing for more aggressive and sophisticated strategies. 　　A more general challenge to real-time performance is responding to interrupts during deep sleep mode. Most on-chip peripherals can be set to "wake up" the system when an interrupt is received, but developers must carefully define strategies to enable (selective) device-based wakeups and consider overall system latencies and memory classes to ensure timely execution of interrupt handlers and user space responses to events (prioritized latency). Reference Platform Capabilities　　While many CPU cores and SoCs (Systems on a Chip) are indeed capable of responding to frequent clock and voltage changes, the reference boards they are built on often cannot. In fact, many CPU reference and evaluation boards cannot adjust clocks and voltages quickly enough for DPM, and many do not allow any real-time adjustments to these parameters at all! In these cases, developers must wait for access to the respective production hardware in order to measure the various power management

　　



　　




　　

　　Embedded Linux Adoption, DPM, and Differentiation Ideally, device users would neither need to know nor care about the underlying operating system in the handsets they purchase. However, “aftermarket” software supplied by operators is giving device manufacturers more visibility
　　into their preferred operating systems and creating brands in an area where they did not exist before. While brand creation has long been a focus for Microsoft, the Windows family has lagged behind Symbian, Brew, and now a variety of new embedded Linux-based designs in high-volume service delivery markets such as the mobile phone market.
One reason device manufacturers are turning to Linux is the opportunity to take advantage of standards-based power management rather than current proprietary solutions. The evolving dynamic power management capabilities, along with power profiling technologies such as ARM's IEM, are providing handset manufacturers and other smart device OEMs with powerful new tools to enhance product differentiation, achieve faster time to market, and meet end-user and operator technology requirements.