Difference between revisions of "Power Management Specification"

From eLinux.org
Jump to: navigation, search
m (Bot (Edward's framework))
 
m (Performance vs. Battery Lifetime Policy)
 
Line 103: Line 103:
  
 
# A kernel SHOULD provide userspace interface for specifying requirements on the lower limit of battery lifetime. If the battery lifetime requirement exists, a kernel SHOULD set the operating state of the task to allocate the remaining energy resource amongst all tasks, based on the task priorities, to satisfy this requirement.
 
# A kernel SHOULD provide userspace interface for specifying requirements on the lower limit of battery lifetime. If the battery lifetime requirement exists, a kernel SHOULD set the operating state of the task to allocate the remaining energy resource amongst all tasks, based on the task priorities, to satisfy this requirement.
 +
[[Category:Specification]]

Latest revision as of 04:04, 14 May 2010

#noprint
VERSION 1.0 - for other versions, click the "info" button.

'''Table Of Contents:'''
[[TableOfContents3]]
#noprint

Introduction

The goal of power management technology is to allow Consumer Electronic (CE) device manufacturers to optimize the power use of their products, including a variety of mobile devices, home appliances, and other end-user devices.

Rationale

In CE products, battery-driven mobile devices have particularly stringent requirements for power management, and this affects the product's competitiveness significantly in specific product categories. Mobile phones and other handheld devices are driven by secondary batteries, not wired power supply. Efficient power usage is required to increase the utilization time of such products.

Power Dissipation Elements in CMOS Circuits

CMOS(Complementary Metal Oxide Semiconductor) circuit has three elements of power dissipation; leakage current, dynamic current, short-circuit current power dissipation. The leakage current power dissipation is caused by the leakage current. The leakage current power dissipation is quadratically dependent on operating voltage but not dependent on clock frequency. The dynamic current power dissipation is caused by the dynamic current which is required for signal transitions. The dynamic power dissipation is quadratically dependent on the voltage and linearly dependent on the frequency of signal transitions. The short-circuit current dissipation is generated by short circuit current when NMOS and PMOS transistors are activated simultaneously. Short-circuit current power dissipation is either linearly or quadratically dependent on the supply voltage, depending on the size of the length of channel between PMOS and NMOS transistors. Of those three elements, the dynamic current power dissipation is a dominant factor because the frequency of signal transitions is very high.

Power Reduction Methods

There are various methods for reducing power consumption: voltage/clock scaling, clock gating, power supply gating, input signal selection and so on.

- The voltage/clock scaling is the method that reduces both the dynamic power dissipation and the static power dissipation by decreasing voltage and clock dependently or independently. 
- The clock gating reduces the dynamic power dissipation by disconnecting the clock from an unused circuit block. 
- The power supply gating disconnects the supply power from unused circuit blocks, which are components of whole circuit. In clock/power supply gating methods, it is important to decide whether the block is used or not and to restore the blocks when they are used again. 
- The input signal selection affects the reduction of the leakage power dissipation. The input signals of CPU pins should be adjusted to minimize the usage of power when the system is suspended.

Voltage scaling is the key to achieve power reduction and energy reduction. As clear from the analysis of the three power dissipation elements, operating voltage plays a major role in power dissipation. Let's take an example to see how voltage/clock scaling can reduce power and energy. If operating voltage is down-scaled from 2.0V to 1.0V, operating frequency is linearly dependent on the operating voltage in practice. So let us assume clock frequency at 1.0V is half of the frequency at 2.0V. In this case, nearly 87.5% of power can be reduced theoretically. In terms of energy, the total energy for finishing a job need to be compared. Please note that energy is the integration of power dissipation over a period of time. The time taken to finish a job at 1.0V is twice as that of 2.0V. So the total energy required to finish a job will be reduced by 75%.

http://tree.celinuxforum.org/docs/PM_formula.jpg

http://tree.celinuxforum.org/docs/PM_DVS.jpg

Clock gating and power supply gating can be used to reduce power usage by unused blocks. It is important to predict correctly the idle period of a hardware block because incorrect prediction may lead to performance degradation due to the latency of reconnecting clock or power to the hardware blocks.

Power Management Architecture

In designing power management architecture for Linux, the followings are kept in mind.

- To design a system-level optimization of power usage involving interactions among application, OS, and hardware.
- To provide a generic power management framework for various hardware platforms

System-level power management is important for coordinating the performance and power dissipation of hardware components in a system. Recently, CPU chip vendors deploy dynamic clock/voltage scaling support in their processors to enable OS-level power management capability. The power reduction techniques offered by hardware components should be synthesized, managed, and adjusted to minimize the power dissipation of the whole system while the requirements of system should be satisfied as well. Existing applications need to be adapted to use the power management capability of operating system and such applications are said to be "Energy-Aware".

The power management architecture is designed to provide a generic framework for various hardware architectures. Hardware specific power control interfaces are abstracted by a power control layer. Power management can be implemented for various hardware platforms by adapting the machine-specific power control layer as necessary.

http://tree.celinuxforum.org/docs/PM_Arch.jpg

In this specification, power management technologies are classified into three categories; platform suspend/resume, device power management, and platform dynamic power management. Platform suspend/resume is aimed at major power state changes at infrequent intervals, while platform dynamic power management is aimed at subtle changes across a wider range of power states at frequent intervals. Platform suspend/resume technology is used for reducing most of power dissipation of a product while the product is idle for a long time. In contrast, dynamic power management is used for reducing power dissipation while a product is being used. Dynamic power management covers also reducing power for very short idle periods of time while a product is busy. Device power management is to suspend/resume devices in a platform, which is used by platform suspend/resume and dynamic power management technologies.

The rest of this specification is organized as follows. In Terminology section, general power management related terminologies are defined. Platform suspend/resume, device power management, and platform dynamic power management are described in separate sections. Work in Progress section describes important on-going projects which are not included in CELF 1.0 spec but need to be considered for next CELF specification.






Work in Progress

Platform suspend/resume

Protocol between Energy-Aware Application and Policy Manager

    1. Energy-aware(EA) application SHOULD register itself to policy manager.
    2. Policy manager SHOULD send system suspend request to all applications registered as EA application.
    3. Energy-aware application SHOULD respond to the system suspend request from policy manager appropriately.
      1. If EA application agree to system suspend, it invokes its suspend handler.
        1. The suspend handler may store important data including user data to a non-volatile storage.
        2. The suspend handler SHOULD send acknowledgement to policy manager and SHOULD wait until it receives resume request from policy manager.
      2. If EA application disagree to system suspend, it SHOULD send negative acknowledgement to policy manager.
    1. If system inactivity which is longer than system timeout threshold is detected, policy manager MUST send system suspend request to EA applications and wait for responses from EA applications.
      1. The policy manager SHOULD provide user interface for initializing the system timeout threshold.
      2. The policy manager SHOULD initialize system timeout threshold to a default value.
      3. The policy manager MAY check device inactivity by periodically reading last access time of device.
    2. If a user has requested system suspend, policy manager SHOULD enforce every EA application to suspend itself and wait for responses from EA applications. An EA application which is enforced to suspend by policy manager SHOULD invoke its suspend handler unconditionally.

Device Power Management

Automatic Device Power Saving

    1. The policy manager set the length of inactivity period for each device.
    2. The period of device inactivity can be detected by PM-engine/device drivers and notified to policy manager via signal.

Dynamic Power Management

Energy-Aware(EA) Application Specification

This specification shall define requirements of energy-aware applications so that application can interact tightly with in-kernel PM-engine to control system power states dynamically adaptive to various application specific environments.

EA application may choose one appropriate operating state among system PM policy. The system policy may be given to the EA application by policy manager or hard-coded, which is dependent on design decisions by system administrator. If the system policy information should be given by policy manager, EA application need to set up a IPC mechanism with the policy manager while it starts up.

For real-time EA applications, the information regarding the real-time task scheduling such as the period of execution and their priorities should be given to in-kernel PM engine via some whatever existing API which we have to choose after extensive discussion on pros and cons of existing APIs. (Linux kernel need to support scheduling periodic real-time tasks.)

There are some cases that an EA application need to change system operating state according to the task's environment. This situation is highly dependent on system constraints which system administrator should know correctly. If a system administrator firmly believe that the operating state of an EA task need to be changed, the decision by system administrator should be respected and the in-kernel PM engine will proceed with the decision. It should be noted that system performance and power consumption efficiency might be greatly hampered if the decision of the system administrator is incorrect. So the system administrator should be very much considerate on changing application operating state.

Performance vs. Battery Lifetime Policy

  1. A kernel SHOULD provide userspace interface for specifying requirements on the lower limit of battery lifetime. If the battery lifetime requirement exists, a kernel SHOULD set the operating state of the task to allocate the remaining energy resource amongst all tasks, based on the task priorities, to satisfy this requirement.