Abstract: Effectively managing the power consumption of embedded systems, especially mobile terminals, is a valuable research topic. Dynamic Power Management (DPM) technology provides an operating system-level power management capability, including dynamic adjustment and management functions for CPU operating frequency and voltage, external bus clock frequency, and external device clock/power. Through user-defined strategies and kernel-provided management functions, power parameters are adjusted in real time to meet the needs of real-time applications. This allows power management parameters to be frequently and with low latency adjusted during short periods of idle time or when tasks are running with low power requirements, thus achieving more refined and 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 occurs when the circuit is working or transitioning to a logic state. Static power consumption occurs when there is no transition due to transistor leakage current: Where C is the capacitor, 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 operating system-level power management, the focus is on active power consumption. Several methods for managing active power consumption can be derived from this: ① Voltage/clock regulation. Reduce active and static power consumption by lowering voltage and clock. ② Clock gating. Stop the circuit clock, i.e., set fc to 0 and Pactive to 0. Disconnect the clock from unused circuit modules 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 and DMA peripherals, through gating. ③ Power supply gating. Disconnect the power supply to 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 it is necessary to be able to correctly predict the idle period of hardware modules. Because re-enabling the clock and power supply of hardware modules will cause a certain delay, incorrect prediction will lead to performance degradation. It can be seen from equation (1) that: lowering the voltage contributes to power consumption to the power of the square; lowering the clock can also reduce power consumption, but it also reduces performance and prolongs the execution time of the same task. Let the energy consumption under 2.0 V high voltage be 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). According to equation (1), it is easy to obtain P_high = 8P_low. Combining the above equations, we can conclude that E_high = 4E_low. Therefore, by selecting the lowest clock frequency required to meet the performance requirements and setting the lowest power supply voltage within the range of clock frequency and operating voltage requirements of various system components, the system power consumption will be greatly reduced. In the example above, the energy required to complete the task can be saved by 75%. 2 Hardware platform support for dynamic power management Reducing the active power consumption of the system by adjusting the 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 (e.g., CD controller, UART, SDRAM controller, etc.). The CPU high-frequency clock is mainly provided by the PLL, and the PLL also provides other frequency clocks for peripheral modules and the SoC bus. Most SoC systems have frequency dividers and multipliers to control these clocks. The PM module mainly manages the system's power supply status. It typically has its own low-frequency, high-accuracy 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 a suspended SoC system. The following example uses the TI OMAP1610 processor, widely used in handheld devices. ① Clock Module. The OMAP1610 provides a digital phase-locked loop (DPLL) to convert the external frequency or crystal oscillator input to a high frequency to supply the OMAP 3.2 core and other on-chip devices. The DPLL output clock can be set by manipulating the DPLL control register DPLL1_CTL_REG. Combined with setting the clock multiplexing register (MUX) and clock control register ARM_CKCTL, the operating frequency of the MPU and DSP, the clocks of MPU and DSP peripherals, the LCD refresh clock, and the TC_CK clock (Traffic Control Clock) can be controlled. ② Power Management Module. The OMAP1610 integrates an Ultra Low Power Module (ULPD) to control the OMAP3.2 clock and manage the OMAP1610's various power management modes. Operating the ULPD control register ULPD_POWER_CTRL allows setting the processor voltage and managing the operating mode. 3. Embedded Linux Dynamic Power Management Software Implementation Embedded Linux has been widely used in power-sensitive embedded devices, especially mobile handheld devices; therefore, designing efficient and sophisticated power management technology is one of the key technologies for successful embedded Linux development. 3.1 Dynamic Power Management Implementation Principle The system operates in several common states with different power level requirements, which contain abundant energy-saving opportunities. The state transitions are shown in Figure 1. ① When the system is running in one of the task states (Task, Task 1, Task+), it can respond to interrupts and enter interrupt handling, or enter an idle or sleep state. Different tasks require different power levels. For example, playing MP3s 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 mode, it can be woken up by an interrupt to handle the interrupt: DPM provides a managed idle mode for more intelligent power saving. ③ After interrupt handling, the system can enter idle mode or return to task mode from the interrupt. ④ The system can enter sleep mode while in task mode. The system can be suspended to RAM or other memory, and peripherals can be turned off to maximize power saving. The system can be required to exit sleep mode through specific events (e.g., defining a UART interrupt). In summary, dynamic power management can be divided into three categories: platform suspension/resumption, device power management, and platform dynamic management. Platform suspension/resumption aims to manage large, infrequent, significant power state changes to reduce power consumption after prolonged periods of product device idleness. Device power management is used to shut down/resume devices in the platform (used in both platform suspension/resumption and dynamic management); while platform dynamic management aims to manage frequently occurring, higher-granularity power state changes. System tasks can be further divided into ordinary tasks and power-monitored tasks. The former's power state is DPM_NO_STATE, and it does not perform power management; the latter is power-sensitive, and its power management state can be set through DPM when it is scheduled (see Figure 1), requiring it to run at different power levels. This paper 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 Implementing power management in the Linux architecture requires the kernel module 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-specific power control layer that manages the power control interface for specific hardware. 3.2.1 Kernel Module Control Model The model mainly consists of operation points, management classes, management policies, etc. ① Power management operation points correspond to platform hardware-related parameters. For example, the TIOMAP1610 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 using TI's DSP code, the last four parameters are uncontrollable and use default values, as listed in Table 1. Among them, the "192 MHz—1.5 V" operating point parameter "1500" indicates that the OMAP3.2 core voltage is 1500 mV; "16" indicates that the DPLL frequency control uses a 12 MHz crystal oscillator input with a 16x multiplier; "1" indicates a frequency divider of 1; "1" indicates that the OMAP3.2 core frequency divider is 1 (so it operates at 192 MHz); "2" indicates that the TC (traffic controller) frequency divider is 2 (so it operates at 96 MHz). ② Class: Multiple operating points form a management class. ③ Strategy: Multiple or one class form a strategy. Generally, the system model can be simplified by directly mapping the DPM strategy to a specific DPM operating point under a system operating state, as listed in Table 2. For complex systems, the DPM strategy can be mapped to a multi-operating-point DPM management class, and then the first operating point in the management class that meets the constraints can be selected based on the operating state switch. Table 2 maps the policies to four operation points, corresponding to the four power states: "sleep", "idle", "task-1", and "task". Unless modified by the user, tasks created by system fork run in the DPM-TASK-STATE state by default, corresponding to the task state in Table 2, with an operation point of 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-grained 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 further divided into the interface layer, the hardware-independent layer, and the kernel hardware-dependent layer (the dashed lines 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 the 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 system call interfaces. 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's power state to hardware parameters. Secondly, the kernel hardware-independent layer provides the power management logic control framework. The power management engine mainly implements API calls, selects the operation point, and provides synchronous and asynchronous logic for operation point setting. 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 and power management layer mainly corresponds to the management of various system buses and device clock and power parameters. 3.2.3 Device Power Management and Driver Constraints DPM can manage device power through LDM. The `device_driver` structure in LDM contains callback functions for device suspend and resume, and the `device` structure contains driver constraints. The device needs to be registered with the corresponding system bus using a registration function during device initialization. For example, the simplified LDM-related parameters for I2C are: I2C driver registration to the MPU public TI peripheral bus: `driver_register(&omap_i2c_driver) platform_device_register(&omap_i2c_device)`. Suspension and resumption functions are implemented in the driver: `omap_i2c_controller_suspen(&omap_i2c_device)`, `omap_i2c_controller_resume(&omap_i2c_device)`. This way, all devices registered to the system have a management interface in sysfs. The power state of devices can be manipulated through these interfaces. In various situations, this interface can be used to suspend devices, such as: when an application explicitly suspends devices not needed in the application; when all devices need to be suspended before the platform suspends; when the DPM sets the system to a device-incompatible state, etc. The DPM also provides device driver constraint checks (frequency-dependent) when managing device power states. For example, when the system power state changes and is ready to run at a new operating point, the drive constraint checks whether the state meets the requirements for normal device operation. If not, and the current operating point's 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 current PLL); if the condition is met, the adjustment function implemented in the device driver is used to switch to the new state. The drive constraint is also used to restrict the DPM operation mode. The constraint only allows DPM to switch the system to a low-power idle state when no device is in use. 4 Conclusion DPM technology implements task-level power management through kernel modules, achieving effective device power management, meeting the needs of embedded Linux, and supplementing the shortcomings of desktop system-based APM and APCI power management technologies. Practice has proven that DPM can achieve good energy-saving effects for embedded systems, especially mobile terminals. Of course, the dynamic power management system still needs further improvement. For example: ① It can collect system load status based on hardware and software, and use Markov, chains, and other methods to accurately predict the power state, thereby designing a more intelligent and effective state switching management strategy; ② The complex relationship between power management and real-time performance requirements still needs to be addressed, etc.