Dynamic Power Management Technology for Embedded Linux systems

Dynamic Power Management Technology for Embedded Linux systems)

How to effectively manage embedded systems, especially the power consumption of mobile terminals, is a very valuable topic. Dynamic Power Management
DPM (dynamic power,
Management) technology provides a power management capability at the operating system level, including dynamic adjustment of CPU operating frequency and voltage, External Bus clock frequency, external device clock/power supply, etc.
Management function. The user layer makes policies to interact with the kernel to provide management functions, real-time adjustment of power parameters while meeting the requirements of real-time system applications, allowing power management parameters to run in a short period of time idle or tasks in a low power supply
When needed, it can be adjusted frequently and with low latency to achieve finer and more intelligent power management.

1. Dynamic Power Management Principle

The total power consumption of a CMOS circuit is the sum of active power consumption and static power consumption. Active Power Consumption is generated when the circuit is working or the logic state is switched. If no conversion occurs, the transistor leakage will cause static power consumption:

Type C is a capacitor, FC is the switching frequency, VDD is the power supply voltage, IQ is the leakage current. C. VDD. FC indicates active power consumption, and vddiq indicates static power consumption. In the design and implementation of operating system-level power supply management, the focus is on active power consumption. There are several ways to manage active power consumption:

① Voltage/clock adjustment. Reduces active and static power consumption by reducing the voltage and clock.

② Select the clock. Stop the circuit clock, that is, set FC to O, and set pactive to 0. Disconnect unused circuit modules to reduce active power consumption. Many CPUs have "idle" or "STOPPED" commands. Some processors can also turn off non-CPU clock modules, such as high-speed cache and DMA peripherals, by means of door-controlled.

③ Select power supply. Disconnect the power supply of unused modules in the circuit. This method requires consideration of the cost of restoring the module.

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

　
From formula (1), we can see that the contribution of voltage reduction to power consumption is 2 power, and the lower clock can also reduce power consumption, but it also reduces performance and prolong the execution time of the same task. Set 2.0
The energy consumption under V high pressure is e high = p high · t, then 1.0
V low pressure energy consumption is e low = P low · 2 T (in practice, the frequency is approximately linear dependent voltage), and then the formula (1) is easy to get p high = 8 P low. In general, we can conclude that E is high = 4E low, so select
To meet the minimum clock frequency required for performance, setting the lowest power supply voltage within the clock frequency and the operating voltage requirements of various system components will greatly reduce the power consumption of the system. The energy required to complete the task in the previous example can be limited.
About 75%.

2 hardware platform support for Dynamic Power Management

Hardware Support is required to reduce the active power consumption of the system by adjusting the voltage and frequency. SoC system 1
There are multiple execution units, such as PM (Power Management) module, OSC (On-chip crystal oscillator) module, PLL (Phase Lock Loop) module, CPU core, and data cache and command cache in CPU core. Other modules are collectively referred to
It is a peripheral module (such as 1, CD controller, UART, and SDRAM Controller ). The high-frequency CPU clock is mainly provided by the PLL, And the PLL also provides other frequencies for the peripheral module and the SoC bus.
Clock. Generally, the SoC system has some divider and multiplier to control these clocks. The PM module mainly manages the power supply status of the system. Generally, it has its own low-frequency, high-accuracy crystal, vibration, to maintain
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 uses
The ti0mapl610 processor is used as an example.

① Clock module. The omapl610 provides a digital phase-controlled lock ring (DPLL) to convert the input of the external frequency or crystal oscillator to a high frequency
To OMAP
3.2 cores and other on-chip devices. You can set the DPLL output clock by operating dplll_ctl_reg, supplemented by setting the clock reuse register (MUX) and clock control.
Registers arm_ckctl to control the Running frequency of MPU and DSP, MPU, DSP peripheral clock, LCD refresh clock, and tc_ck clock (trafflc
Control clock.

② Power management module. Omapl610 integrates an ultra-low power control module (ulpd) to control omap3.2 clock and to control omapl610 In and Out of multiple power management modes. You can operate the ulpd control register ulpd_power_ctrl to set the processor voltage and manage the running mode.

3 embedded Linux Dynamic Power Management Software Implementation

Embedded Linux has been widely used in embedded power-sensitive devices, especially mobile handheld devices. Therefore, designing efficient and precise power management technology is one of the key technologies for successful development of embedded Linux.

3.1 Implementation principle of Dynamic Power Management

The system runs in several common states and has different power supply levels, which contains a wealth of energy-saving opportunities. Status Transition 1 is shown.

① When the system is running in task, Task 1, and task +, it can respond to the interruption and enter the interrupt processing status, and enter the idle or sleep status. Different tasks require different power levels. For example, playing MP3 can reduce the processor frequency, while running online interactive games requires the processor to run at full speed, therefore, DPM needs to provide power management services in different tasks.

② When the system enters idle state, the system can be awakened by interruption to handle interruptions: DPM provides a managed idle mode, which can intelligently save power.

③ After the interrupt processing, the system can enter the idle state or return to the task state from the interrupt.

④ The system enters sleep mode in the task state. The system can be mounted to Ram or other memory, and Peripherals can be disabled to maximize power consumption. The system is required to exit sleep mode through specific events (such as defining UART interruptions.

　
To sum up, dynamic power management can be divided into three categories: Platform suspension/recovery, device power management, and platform dynamic management. Platform suspension/recovery aims at managing large and insightful major Power status changes
Changes to reduce power consumption after the product device is idle for a long time. Device power management is used to shut down/recover devices on the platform (both platform suspension/recovery and dynamic management are required ).
The management goal is to manage the power supply status within the scope of frequent and higher granularity changes. Tasks run by the system can be divided into common tasks and power-monitored tasks. The former power supply status is
Dpm_no_state, without power management; the latter is sensitive to power. When being scheduled (see figure 1), you can use DPM to set its power management status, which must run at different power levels. This article
It mainly describes the platform's dynamic power management and device power management, and regards the device power management as an integral part of dynamic power management.

3.2 platform Dynamic Power Management Design

In a Linux architecture, implementing the power management kernel module requires an interface between the application layer and the operating system, and 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 consists of operation points, management classes, and management policies.

　
① Use the power management operation point to correspond to platform hardware related parameters. For example, the tiomapl610 reference Development Board has multiple parameters: CPU voltage, DPLL Frequency Control (through the frequency divider and frequency divider parameters)
Number), CPU frequency control, TC traffic controller, External Device Control, DSP operation frequency, dsp mmu unit frequency, and LCD refresh frequency. If TI's DSP code is used, the last four parameters
The number is uncontrollable and the default value is used, as shown in table 1.

The "192 MHz-1.5 v" Operation Point parameter "1 500" indicates that the omap3.2 core voltage is 1 500
MV; "16" indicates DPLL frequency control 12
MHz crystal oscillator input 16 multiplier; "1" indicates that the frequency is 1; "1" indicates that the core frequency of omap3.2 is 1 (so it runs at 192
MHz) "2" indicates that the TC (Traffic Controller) is divided into 2 (so it runs at 96 MHz ).

Class 2: Multiple operation points constitute a management class.

③ Policy: policies consist of multiple or one class.

Generally, you can simplify the system model and directly map the DPM policy to a specific DPM operation point in the system operation state, as shown in table 2. The system can consider ing the DPM policy to the DPM management class of a Multi-operation point, and then select the first operation point in the management class that meets the constraints when switching the operation status.

Table 2 Maps policies to four operation points, corresponding to "Sleep ",
"Idle", "task-1", and "task" Power status. Tasks created by the system fork run in the DPM-TASK-STATE state by default, corresponding to the task state in Table 2, with the operation point 192, unless the user changes it
MHz-1.5 v.

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

3.2.2 kernel function implementation

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

First, the user layer can perform power management through the sysfs file system provided by the kernel and the device driver model (LDM) interface. The DPM implementation also provides the proc interface to implement power management commands. You can also add the system call interface to make it easier for your program to call the DPM function.

Add dpm_set_ OS (task_dpm _
State) interface, and then the power management engine sets the current task power status to hardware parameters.

Second, the kernel hardware-independent layer provides a logic control framework for power management. The Power Management Engine calls APIs, selects operation points, and provides synchronous and asynchronous logic for Operation Point settings.

The device power management module also implements Device Driver constraints. It uses the LDM interface to manage the device clock and power supply, and provides suspension and recovery control.
The device clock power off layer mainly corresponds to various bus and device clock Power Supply parameter management of the system.

3.2.3 device power management and driver Constraints

DPM enables device power management through LDM. In LDM, The device_driver structure has callback functions such as device suspension and recovery, and the device structure has driver constraints. You need to use the registration function to register the device with the corresponding system bus during device initialization. For example, the LDM parameter of the simplified 12C is:

　　
　
The I2C driver is registered with the MPU public Ti Peripheral Bus: driver_reg-
Ister (& omap_i2c_driver) platform_device_register (& omap_i2c_device ).
Implement the suspension and recovery letter in the driver
Number: omap_i2c_controller_suspen (& omap_i2c_device), omap_i2c_con-
Troller_resume (& omap_i2c_deviee ). In this way, all devices registered to the system have a management interface in sysfs. Through these interfaces
Allows you to manipulate the power status of a device. You can use this interface to hang up a device in multiple cases. For example, an application explicitly hangs up a device that is not needed by the application. Before the platform is suspended, all devices need to be hung up. When DPM hangs the system
The device must be suspended when it is set to incompatible with the device. When managing the power status of a device, DPM also provides a device drive constraint check (Frequency-related ). For example, when the system power status changes
When operating, the driver constraints check whether the status meets the normal operation of the device. If not, and the Force attribute of the current operation point is set to 1, the device is first shut down by the LDM callback function (or the device is placed in
In this case, the PLL is suspended). If conditions are met, the adjustment function implemented in the device driver is used to change to the new State.

Driver constraints are also used to limit the DPM operation mode. When no device is in use, the constraint allows DPM to turn the system to a low-power idle state.

4. Summary

The DPM technology implements task-level power management through the kernel module, and implements effective device power management, meeting the requirements of embedded Linux, the shortcomings of APM and APCI power management technologies based on the desktop system are supplemented. Practice has proved that DPM can effectively save energy 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, chain, and other means to design a more intelligent and effective state switching management strategy; ② the complex relationship between power management and real-time performance requirements still needs to be handled.