This is the documentation for the latest (main) development branch of Zephyr. If you are looking for the documentation of previous releases, use the drop-down menu on the left and select the desired version.

System Power Management

The kernel enters the idle state when it has nothing to schedule. If enabled via the CONFIG_PM Kconfig option, the Power Management Subsystem can put an idle system in one of the supported power states, based on the selected power management policy and the duration of the idle time allotted by the kernel.

It is an application responsibility to set up a wake up event. A wake up event will typically be an interrupt triggered by one of the SoC peripheral modules such as a SysTick, RTC, counter, or GPIO. Depending on the power mode entered, only some SoC peripheral modules may be active and can be used as a wake up source.

The following diagram describes system power management:

System power management

Some handful examples using different power management features:

Power States

The power management subsystem contains a set of states based on power consumption and context retention.

The list of available power states is defined by pm_state. In general power states with higher indexes will offer greater power savings and have higher wake latencies.

Power States Constraint

The power management subsystem allows different Zephyr components and applications to set constraints on various power states preventing the system from transitioning into these states. This can be used by devices when executing tasks in background to prevent the system from going to a specific state where it would lose context. Constraints can be set using the pm_constraint_set(), released using pm_constraint_release() and checked using the pm_constraint_get().

Power Management Policies

The power management subsystem supports the following power management policies:

  • Residency based

  • Application defined

The policy manager is responsible for informing the power subsystem which power state the system should transition to based on states defined by the platform and possible runtime constraints

More details on the states definition can be found in the zephyr,power-state binding documentation.


The power management system enters the power state which offers the highest power savings, and with a minimum residency value (see zephyr,power-state) less than or equal to the scheduled system idle time duration.

This policy also accounts for the time necessary to become active again. The core logic used by this policy to select the best power state is:

if (time_to_next_scheduled_event >= (state.min_residency_us + state.exit_latency))) {
   return state


The application defines the power management policy by implementing the pm_policy_next_state() function. In this policy the application is free to decide which power state the system should transition to based on the remaining time for the next scheduled timeout.

An example of an application that defines its own policy can be found in tests/subsys/pm/power_mgmt/.