Power Management Definition Of Terms
Definition of Terms for Power Management working group
Classes In the future, a Class will be a set of Operating Points. DPM will be architected to choose the appropriate Operating Point for the current Class, based on constraints. The current implementation of DPM restricts each Class to contain only one Operating Point. Continuing the above example of device constraints for a network adapter, if a Class contained two Operating Points, "slow_cpu_fast_io" which specified an IO bus frequency of 25 MHz and "slow_cpu_slow_io" which specified an IO bus frequency of 5 MHz, then DPM would not be able to set the Operating Point to "slow_cpu_slow_io" while the network adapter was active.
Device constraints Constraints describe the required relationships between the hardware operating parameters. For example, for a network adapter to function properly, it might be required that the frequency of the IO bus to which it is attached must be greater than 10 MHz.
DPM The Monta Vista Dynamic Power Management subsystem
Operating Points An Operating Point is a specific set of values of power parameters. The system designer chooses an Operating Point to reflect a certain level of system performance together with an associated level of energy consumption.
Hibernate See Suspend-to-Disk
Operating States The Operating State reflects the current state of the system: executing a task, processing interrupts, or idle. Each process has an associated Operating State, as does the system idle loop and the interrupt handling code path. It is also an abstraction that software uses to request a specific level of system performance, since there are multiple operating states that can be associated with a task, and the various operating states may be mapped to differing Operating Points, thus causing differing levels of performance and power consumption for different tasks. The current system Operating State is set to the Operating State of the process currently executing (or the idle loop or interrupt handlers). The board specific implementation portion of DPM may also alter the system's current Operating State while kernel code is executing. For example, the kernel idle loop code may explicitly set the system's current Operating State to "idle" while there is no task that is ready to execute.
Policy Manager Software that dynamically sets the current policy from the set of defined policies. The Policy Manager selects the current Policy based on certain system conditions. For example, the Policy Manager can select the Current Policy in one of the following ways: 1. If the user presses the device's soft-power switch, the Policy Manager can choose an ultra_low_power Class; 2. If remaining battery power reaches a threshold, the Policy Manager may choose a lower_power_and_performance Class; 3. If the device is connected to main power, the Policy Manager may choose a high_performance Class.
Power Control Layer Power control layer is the software layer on top of which power management framework sits. This layer provides H/W specific power control methods to power management framework with abstracted power control interfaces.
Power Management Framework Power management framework in kernel maintains system power management policy and implements core functions for static power management and dynamic power management technologies. PM framework plays the role of coordinating energy resource among multiple tasks and adapting system operating state according to task specific requirements.
Power Parameters Power parameters are the hardware parameters that may be modified to affect the power usage of the platform, such as clock frequencies or dividers, voltage levels, and so forth.
Power Policy A Policy is a mapping of which Class is invoked for each Operating State. For example, a "power-off" policy may map all Operating States to an extremely low power Class; a "power-off-fast-wakeup" may map all Operating States to a low power and low wakeup latency Class; and a "active" policy may map an Operating State used by interactive processes to a high power Class, an Operating State used by background processes to a medium power Class, and an Operating State used by the kernel idle loop to a low power and low wake up latency Class. Whenever the Operating State changes (due to an explicit request or implicitly due to a change of which process is currently executing) DPM uses the current Policy to determine which Class is associated with the new Operating State. DPM selects the best Operating Point from the new Class, and then sets the hardware parameters defined by the Operating Point.
Suspend/Resume System suspend refers to placing the system in a low-power state with many components powered off, or perhaps entirely powering off the system after saving state to stable storage. This is a relatively lengthy procedure undertaken when an extended period of product inactivity is expected, as for example when the user presses a "standby" button on the product or the product has not been in use for a long period of time. This procedure can thus be distinguished from the power state changes appropriate for a running system driven by technologies such as Dynamic Power Management, which are executed more quickly during very brief idle periods. System resume refers to the process of restoring the state of the system to approximate pre-suspend conditions upon resume.
Suspend-to-Disk/Hibernate A technique by which systems preserve state on disk during suspend and restore system state from disk upon resume. This is typically done on platforms where all of RAM may be saved to a disk device and then the RAM (and perhaps the entire system) may be powered off during the suspend period. This is commonly referred to as "hibernating" for laptop/notebook computers.
Suspend-to-RAM A technique by which systems preserve state in RAM during suspend and restore system state from RAM upon resume. This is necessary on platforms that remove power from some portions of the system, such as the CPU core or I/O core, but maintain power to SDRAM during the suspend period
Suspend modes / Standby modes / Sleep modes A platform may support more than one suspend mode, that is, system behavior during a suspend may differ depending on what suspend mode has been requested. For example, one mode may stop certain clocks during suspend but leave all components powered on, while another mode may power off various components (such as the CPU core or I/O modules) but leave others powered on (such as to leave SDRAM in self-refresh state), and so forth.