Dynamic Power Management Technology for Embedded Linux

wenhui

Dynamic Power Management Technology for Embedded Linux [Copy link]

Abstract Based on the power management support of SoC hardware, the tasks created by the system are linked to the specific power management hardware parameters by designing power management operation points, management classes, management strategies and other structures, providing a framework structure including application layer, operating system layer and hardware layer for fine power management between tasks. Combined with the strategies formulated by the user layer, the dynamic power consumption of the system is managed in real time, dynamically and with low latency, and the CPU operating frequency and voltage, external bus clock frequency, and external device clock/power parameters are adjusted. Practice has proved that the energy saving effect is good.
Keywords Embedded Linux Dynamic Power Management Intelligent Terminal DPM

Introduction
How to effectively manage the power consumption of embedded systems, especially mobile terminals, is a very valuable topic. Dynamic Power Management DPM (Dynamic Power, Management) technology provides an operating system-level power management capability, including dynamic adjustment and management functions of CPU operating frequency and voltage, external bus clock frequency, external device clock/power, etc. Through the interaction of user layer-formulated strategies and kernel-provided management functions, power parameters are adjusted in real time while meeting the needs of real-time applications of the system, allowing power management parameters to be adjusted frequently and with low latency when idle for a short time or when tasks are running with low power requirements, thereby achieving more refined and intelligent power management.

1 Principle of dynamic power management
The total power consumption of CMOS circuit is the sum of active power consumption and static power consumption. When the circuit is working or the logic state is switched, active power consumption is generated. When no switch occurs, transistor leakage current will cause static power consumption:

Where C is the capacitance, fc is the switching frequency, Vdd is the power supply voltage, and IQ is the leakage current. C·Vdd·fc is the active power consumption; VddIQ is the static power consumption. In the design and implementation of power management at the operating system level, the focus is on active power consumption. From this, several methods for managing active power consumption can be derived:
① Voltage/clock regulation. Reduce active power consumption and static power consumption by reducing voltage and clock.
② Clock gating. Stop the circuit clock, that is, set fc to 0 and let Pactive be 0. Disconnect the clock from the unused circuit module to reduce active power consumption. Many CPUs have "idle" or "stop" instructions, and some processors can also shut down non-CPU clock modules such as cache, DMA peripherals, etc. through gating.
③ Power supply gating. Disconnect the power supply of unused modules in the circuit. This method needs to consider the cost of restoring the module.

Disconnecting the clock and power supply of unused modules can reduce power consumption, but it is necessary to correctly predict the idle period of the hardware module. Because re-enabling the clock and power supply of the hardware module will cause a certain delay, incorrect prediction will lead to performance degradation.

From formula (1), it can be seen that the contribution of lowering the voltage to power consumption is quadratic; lowering the clock can also reduce power consumption, but it also reduces performance and prolongs the execution time of the same task. Assuming that the energy consumption under 2.0 V high voltage is E high = P high · T, then the energy consumption under 1.0 V low voltage is E low = P low · 2T (in practice, the frequency is approximately linearly dependent on the voltage), and then according to formula (1), it is easy to get P high = 8P low. Combining the above formula, it can be concluded that: E high = 4E low, so choosing the lowest clock frequency required to meet the performance requirements, setting the lowest power supply voltage within the clock frequency and the operating voltage requirements of various system components will greatly reduce system power consumption. In the above example, the energy required to complete the task can be saved by 75%.

2 Hardware platform support for dynamic power management
Reducing system activity power consumption by adjusting voltage and frequency requires hardware support. SoC systems generally have multiple execution units, such as PM (power management) module, OSC (on-chip crystal oscillator) module, PLL (phase-locked loop) module, CPU core, and data cache and instruction cache in the CPU core. Other modules are collectively referred to as peripheral modules (such as 1, CD controller, UART, SDRAM controller, etc.). The CPU high-frequency clock is mainly provided by PLL, and PLL also provides other frequency clocks for peripheral modules and SoC bus. Generally, SoC systems have some dividers and multipliers to control these clocks. The PM module mainly manages the power supply status of the system. Generally, it has its own low-frequency, high-precision crystal oscillator to maintain an RTC clock, RTC timer and interrupt control unit. The interrupt control unit enables the RTC timer and external devices to wake up the suspended SoC system. The following takes a TI0MAP1610 processor widely used in handheld devices as an example.

① Clock module. OMAPl610 provides a digital phase-locked loop (DPLL) that converts external frequency or crystal input into high frequency and supplies it to the OMAP 3.2 core and other on-chip devices. By operating the DPLL control register DPLLl_CTL_REG, the DPLL output clock can be set. By setting the clock multiplexing register (MUX) and the clock control register ARM_CKCTL, the operating frequency of the MPU and DSP, the MPU and DSP peripheral clocks, and the LCD refresh clock, TC_CK clock (Trafflc Control Clock), etc. can be controlled.

② Power management module. OMAPl610 integrates an ultra-low power control module (ULPD) to control the OMAP3.2 clock and control OMAPl610 to enter and exit various power management modes. By operating the ULPD control register ULPD_POWER_CTRL, the processor voltage can be set and the operating mode can be managed.

3 Implementation of dynamic power management software in embedded Linux
Embedded Linux has been widely used in embedded devices that are sensitive to power consumption, especially mobile handheld devices; therefore, designing efficient and sophisticated power management technology is one of the key technologies for the successful development of embedded Linux.

3.1 Principle of dynamic power management implementation
The system runs in several common states with different power level requirements, which contains abundant energy-saving opportunities. The state transition is shown in Figure 1.

① The system runs in one of the task states of Task, Task 1, and Task +. It can respond to interrupts and enter interrupt processing, and can enter idle or sleep state. Different tasks require different power levels. For example, playing MP3 can reduce the frequency of the processor, while running online interactive games requires the processor to run at full speed, so DPM needs to provide power management services in different tasks.
② The system enters idle state and can be awakened by interrupts at this time. Processing interrupts: DPM provides managed idle mode, which can save power more intelligently.
③ The system can enter idle state after interrupt processing, or return to task state from interrupts.
④ The system can enter sleep mode in task state. The system can be suspended to RAM or other storage, turn off peripherals, and achieve maximum power saving. The system is required to exit sleep mode through specific events (such as defining UART interrupts).

In summary, dynamic power management can be divided into three categories: platform suspend/resume, device power management, and platform dynamic management. The goal of platform suspend/resume is to manage large, uncommon and significant power state changes, which is used to reduce power consumption of product devices after long periods of idleness. Device power management is used to shut down/restore devices in the platform (used in both platform suspend/resume and dynamic management); while platform dynamic management aims to manage frequently occurring, higher-granularity power state changes. Tasks running in the system can be divided into ordinary tasks and power-monitored tasks. The power state of the former is DPM_NO_STATE and no power management is performed; the latter is power-sensitive and can be set to its power management state by DPM when scheduled (see Figure 1), requiring it to run at different power levels. This article focuses on describing two categories: platform dynamic power management and device power management, and regards device power management as a component of dynamic power management.

3.2 Platform dynamic power management design
To implement the power management kernel module under the Linux architecture, it is necessary to implement an interface between the application layer and the operating system, a hardware-independent layer that provides a general power management logic control framework for multiple hardware platforms, and a platform-related power control layer that manages specific hardware power control interfaces.

3.2.1 Kernel module control model
The model mainly consists of operation points, management classes, management policies, etc.
① Use power management operation points to correspond to platform hardware-related parameters. For example, the TIOMAPl610 reference development board has multiple parameters: CPU voltage, DPLL frequency control (through two parameters, frequency multiplier and frequency divider), CPU frequency control, TC traffic controller, external device control, DSP operating frequency, DSP MMU unit frequency and LCD refresh frequency. If TI's DSP code is used, the last four parameters are uncontrollable and all use default values, as listed in Table 1.

Among them, the "192 MHz-1.5 V" operating point parameter "1500" means that the OMAP3.2 core voltage is 1500 mV; "16" means that the DPLL frequency controls the 12 MHz crystal input 16 times; "1" means the frequency division is 1; "1" means that the OMAP3.2 core frequency division is 1 (so it runs at 192 MHz) "2" means that the TC (traffic controller) frequency division is 2 (so it runs at 96 MHz).
② Class: Multiple operating points form a management class.
③ Strategy: Multiple or one class constitutes a strategy.

Generally, the system model can be simplified and the DPM strategy can be directly mapped to a specific DPM operating point in a system operating state, as listed in Table 2. For complex systems, the DPM strategy can be mapped to a DPM management class with multiple operating points, and then the first operating point in the management class that meets the constraints is selected when the operating state is switched.

The strategies in Table 2 are mapped to four operating points, corresponding to the four power states of "sleep", "idle", "task-1" and "task". Unless the user changes it, the task created by the system fork runs in the DPM-TASK-STATE state by default, corresponding to the task state in Table 2, and its operating point is 192 MHz-1.5 V.

Through this structure, the power management system connects the tasks created by the system with the specific power management hardware unit parameters, providing a framework for fine power management between tasks.

3.2.2 Kernel function implementation
As shown in Figure 2, the DPM software implementation can be divided into several parts, including the application layer, kernel layer, and hardware devices. The kernel layer can be divided into the interface layer, the hardware-independent layer, and the kernel hardware-related layer (the dotted line part in Figure 2), which can be described in the following aspects.

First, the user layer can perform power management through the sysfs file system and device driver model (LDM) interface provided by the kernel. The DPM implementation also provides a Proc interface to implement power management commands; it can also make it easier for user programs to call DPM functions by adding a system call interface.

By modifying the task switching macro switch_tO and adding the dpm_set_OS (task_dpm_ state) interface, the power management engine sets the current task power state to the hardware parameters.

Second, the kernel hardware-independent layer provides a power management logic control framework. The power management engine mainly implements API calls, selects operation points, and provides synchronous and asynchronous logic for operation point settings. The

device power management module also implements device driver constraints, manages device clocks and power through the LDM interface, and provides suspend and resume control. The device clock power layer mainly corresponds to the management of various bus and device clock power parameters of the system.

3.2.3 Device power management and driver constraints
DPM can manage the power of devices through LDM. The device_driver structure in LDM has callback functions such as device suspend and resume, and the device structure has driver constraints. The registration function needs to be used to register the device to the corresponding system bus when the device is initialized. For example, the simplified LDM-related parameters of 12C are:

The I2C driver is registered to the MPU public TI peripheral bus: driver_register(&omap_i2c_driver) platform_device_register(&omap_i2c_device). The suspend and resume functions are implemented in the driver: omap_i2c_controller_suspen(&omap_i2c_device), omap_i2c_controller_resume(&omap_i2c_device). In this way, all devices registered to the system have a management interface in sysfs. These interfaces can be used to manipulate the power state of the device. In many cases, this interface can be used to hang up the device, for example: the application explicitly hangs up the device that is not needed in the application; all devices need to be hung up before the platform is suspended; when the DPM sets the system to an incompatible state for the device, the device needs to be suspended, etc. Among them, the DPM also provides device driver constraint checks (frequency-related) when managing the device power state. For example, when the system power state changes and is ready to run at a new operating point, the driver constraint checks whether the state satisfies the normal operation of the device. If not, and the current operating point force attribute is set to 1, the device is first shut down by the LDM callback function (or the device is placed in a suspended state corresponding to the PLL at this time); if the conditions are met, the adjustment function implemented in the device driver is used to switch to a new state.

Driver constraints are also used to restrict the DPM operation mode. When no device is in use, the constraints allow the DPM to switch the system to a low power idle state.

4 Conclusion
DPM technology implements task-level power management and effective device power management through kernel modules, meets the needs of embedded Linux, and supplements the deficiencies of APM and APCI power management technologies based on desktop systems. Practice has proved that DPM can achieve good energy-saving effects on embedded systems, especially mobile terminals.

Of course, the dynamic power management system needs to be further improved. For example: ① The system load status can be collected based on hardware and software, and the power status can be accurately predicted using Markov,chains and other means, so as to design a smarter and more effective state switching management strategy; ② The complex relationship between power management and real-time performance requirements needs to be processed, etc.