Power Management for Series 2#

Zephyr supports several modes of power management. See the upstream documentation for an overview of the different modes:

  • CONFIG_PM: System Power Management - handles suspending the CPU and entering sleep states.

  • CONFIG_PM_DEVICE: Device Power Management - handles suspending and resuming device drivers:

    • CONFIG_PM_DEVICE_SYSTEM_MANAGED: System-Managed Device Power Management - device drivers are suspended and resumed together with the CPU.

    • CONFIG_PM_DEVICE_RUNTIME: Device Runtime Power Management - device drivers have an independent lifecycle from the CPU.

On Silicon Labs devices, system-managed device power management is not considered particularly useful, because it limits the use of the rich set of autonomous peripherals capable of operating while the CPU is asleep.

System Power management#

On Silicon Labs Series 2 devices, system power management is implemented using the Silicon Labs Power Manager, which acts as a backend for the Zephyr Power Management subsystem.

The Zephyr PM subsystem determines the desired sleep state based on its power management policy. This decision is passed to Silicon Labs Power Manager as an Energy Mode requirement. The Silicon Labs Power Manager performs the action of going to sleep, taking other direct requirements into account in addition to the Zephyr decision. This includes Energy Mode requirements from the radio subsystem through RAIL and any other Silicon Labs stacks and services that may be used in the future.

The Silicon Labs Power Manager may choose a shallower sleep state than Zephyr requests if another subsystem requires it.

The Silicon Labs Power Manager integrates with the Sleeptimer and HFXO Manager to optimize the sleep cycle to maximize the sleep duration while waking in time to restore required oscillators, etc. The Sleeptimer must be used as the OS timer in Zephyr when Power Management is enabled. By default, this is the case due to the Kconfig option CONFIG_SILABS_SLEEPTIMER_TIMER defaulting to enabled. By default, the Sleeptimer is backed by the SYSRTC or RTCC peripheral, depending on availability.

Device Runtime Power Management#

Most drivers for Silicon Labs Series 2 peripherals integrate with Device Runtime Power Management by implementing the SUSPEND and RESUME power management actions.

The RESUME action typically includes:

  • Enabling the clock branch.

  • Configuring pinctrl to the default state.

  • Enabling the peripheral.

The SUSPEND action typically takes the opposite actions:

  • Disabling the peripheral.

  • Configuring pinctrl to the sleep state (if it exists).

  • Enabling the clock branch.

Because Device Runtime Power Management requires correct reference counting using the pm_device_driver_get(dev) and pm_device_driver_put(dev) APIs by all subsystems using the driver, Device Runtime Power Management is disabled for Silicon Labs peripheral drivers by default, even if CONFIG_PM_DEVICE_RUNTIME is enabled.

To opt in to Device Runtime Power Management for a specific peripheral, set the zephyr,pm-device-runtime-auto property on the DTS node of the peripheral. If this property is not set, the device will behave as if Device Runtime Power Management was not enabled -- the RESUME action will be called once at boot and the device will stay active for the lifetime of the program.

Pinctrl Sleep State#

Devices that integrate with Device Runtime Power Management use the pinctrl sleep state if it exists in their SUSPEND action. This helps deallocate GPIO pins when the device is inactive -- either to save power by putting the pins in a power-saving configuration or to free pins for use by other drivers.

The DISABLED state is the GPIO state typically used for this purpose. It is configured by giving no additional properties in the pinctrl group other than the list of pins and optionally bias-pull-up. Configuring this state also ensures that DBUS routes are deallocated for the pin. See the Pin Configuration documentation for a full mapping between Silicon Labs GPIO modes and Zephyr pinctrl properties.

Depending on the board, the power savings of using a pinctrl sleep state may be marginal, and the energy cost of executing the code that reconfigures the pinout may not be recouped. If the purpose of pinctrl sleep is energy savings, the given use case should be profiled to discover if it is worth it.