Power Management (PM)
Relevant source files
The following files were used as context for generating this wiki page:
The Power Management (PM) subsystem in Zephyr provides a framework for system integrators to leverage the power-saving features of modern SoCs. It allows the kernel to transition an idle system into various power states based on residency requirements and application-defined policies. By managing both system-level and device-level power states, the subsystem ensures that energy consumption is minimized while maintaining system responsiveness.
Sources: doc/services/pm/index.rst, doc/services/pm/system.rst:4-9
System Power Management Architecture
The kernel enters an idle state when there are no threads to schedule. If CONFIG_PM is enabled, the kernel calls the PM subsystem to transition the SoC into a supported power state. The PM subsystem calculates the potential idle duration and selects an appropriate state using a policy manager.
System Suspend Flow
The following diagram illustrates the logical flow of the pm_system_suspend() routine, which handles the transition from active execution to a low-power state and back.
The flow ensures that interrupts are managed and devices are properly suspended before the SoC enters a low-power mode.
Sources: doc/services/pm/system.rst:20-61
Power Management Policies
The PM subsystem uses a Policy Manager to decide which power state the system should enter. There are two primary built-in policies:
Residency Policy
Under this policy, the system selects the state with the highest power savings where the sum of minimum residency and exit latency is less than or equal to the scheduled idle time.
| Condition | Logic |
|---|---|
| Calculation | idle_time >= (state.min_residency + state.exit_latency) |
Sources: doc/services/pm/system.rst:83-93
Application-Defined Policy
Applications can override the default behavior by implementing the pm_policy_next_state function. This provides full control over state transitions based on custom application logic.
Sources: doc/services/pm/system.rst:95-101
Custom Ticks Hook
When CONFIG_PM_CUSTOM_TICKS_HOOK is enabled, the PM core can derive wake-up times from hardware-specific or proprietary sources via pm_policy_next_custom_ticks(). The core then selects the earliest expiration from the kernel tick, the policy event list, or this custom hook.
Sources: doc/services/pm/system.rst:103-120
Power States and Device Management
The subsystem defines power states in the pm_state enum. Generally, states with a higher index offer greater savings but higher wake-up latencies.
| Component | Description |
|---|---|
| Policy Manager | Decides the next system power state. |
| Power States | Defined in Devicetree via zephyr,power-state bindings. |
| State Locking | Components can use pm_policy_state_lock_get to prevent transitions to specific states during background tasks. |
| Device PM | If CONFIG_PM_DEVICE is enabled, the subsystem handles suspending and resuming peripheral drivers during system transitions. |
Sources: doc/services/pm/system.rst:64-71, doc/services/pm/system.rst:122-128
Security and Safety Considerations
The PM subsystem is integrated into the broader Zephyr quality and security frameworks.
- Secure Design: PM follows the "Least Privilege" and "Economy of Mechanism" principles. Features or services are not enabled by default to reduce the attack surface.
- Safety Scope: Functional safety certification for standards like IEC 61508 (SIL 3) involves verifying that power management functionalities can be disabled (e.g., via Kconfig) if they are not suitable for a specific safety application.
- Traceability: PM requirements are tracked in the requirements catalog to ensure implementation satisfies documented behavior for certification purposes.
Sources: doc/security/secure-coding.rst:64-85, doc/safety/safety_overview.rst:155-165, doc/project/documentation.rst:15-20
Conclusion
Power Management in Zephyr is a highly configurable subsystem that balances power efficiency with system performance. By utilizing the Policy Manager and Devicetree-defined power states, developers can tailor power consumption to the specific needs of their hardware and application, supported by a robust architecture that accounts for both device-level and system-level transitions.