Lines Matching +full:power +full:- +full:on
1 Device Power Management
7 Device power management (PM) on Zephyr is a feature that enables devices to
10 selected, device drivers implementing power management will be able to take
11 advantage of the device power management subsystem.
13 Zephyr supports two methods of device power management:
15 - :ref:`Device Runtime Power Management <pm-device-runtime-pm>`
16 - :ref:`System-Managed Device Power Management <pm-device-system-pm>`
18 .. _pm-device-runtime-pm:
20 Device Runtime Power Management
23 Device runtime power management involves coordinated interaction between
25 play a crucial role in directly controlling the power state of
34 - **Device drivers** are responsible for managing the
35 power state of devices. They interact directly with the hardware to
36 put devices into low-power states (suspend) when they are not in
38 :ref:`device runtime power management APIs <device_runtime_apis>` provided
39 by Zephyr to control the power state of devices.
41 - **Subsystems**, such as sensors, file systems,
42 and network, can also influence device power management.
46 subsystem may decide to keep a network interface powered on if it
49 - **Applications** running on Zephyr can impact device
50 power management as well. An application may have specific
51 requirements regarding device usage and power consumption. For
53 to keep the network interface powered on continuously.
56 key to efficient device power management. For example, a device driver
58 operations that require a device to remain powered on. In such cases,
59 the subsystem can use device runtime power management to ensure that
63 When using this Device Runtime Power Management, the System Power
64 Management subsystem is able to change power states quickly because it
68 For more information, see :ref:`pm-device-runtime`.
70 .. _pm-device-system-pm:
72 System-Managed Device Power Management
75 The system managed device power management (PM) framework is a method where
76 devices are suspended along with the system entering a CPU (or SoC) power state.
78 When using this method, device power management is mostly done inside
81 If a decision to enter a CPU lower power state is made, the power management
82 subsystem will check if the selected low power state triggers device power
89 The decision about suspending devices when entering a low power state is done based on the
90 state and if it has set the property ``zephyr,pm-device-disabled``. Here is
91 an example of a target with two low power states with only one triggering device power
94 .. code-block:: devicetree
98 power-states {
100 compatible = "zephyr,power-state";
101 power-state-name = "standby";
102 min-residency-us = <5000>;
103 exit-latency-us = <240>;
104 zephyr,pm-device-disabled;
107 compatible = "zephyr,power-state";
108 power-state-name = "suspend-to-ram";
109 min-residency-us = <8000>;
110 exit-latency-us = <360>;
117 When using :ref:`pm-system`, device transitions can be run from the idle thread.
121 This method of device power management can be useful in the following scenarios:
123 - Systems with no device requiring any blocking operations when suspending and
125 power management.
126 - For devices that can not make any power management decision and have to be
133 :ref:`Device Runtime Power Management <pm-device-runtime-pm>` is the
134 **preferred** method for implementing device power management.
138 When using this method of device power management, the CPU will not
139 enter a low-power state if a device cannot be suspended. For example,
140 if a device returns an error such as ``-EBUSY`` in response to the
143 prevents the CPU from entering a low-power state is if the option
149 Devices are suspended only when the last active core is entering a low power
152 Device Power Management States
155 The power management subsystem defines device states in
156 :c:enum:`pm_device_state`. This method is used to track power states of
178 ACTIVE -> SUSPENDING -> SUSPENDED;
179 ACTIVE -> SUSPENDED ["label"="PM_DEVICE_ACTION_SUSPEND"];
180 SUSPENDED -> ACTIVE ["label"="PM_DEVICE_ACTION_RESUME"];
184 OFF -> SUSPENDED ["label"="PM_DEVICE_ACTION_TURN_ON"];
185 SUSPENDED -> OFF ["label"="PM_DEVICE_ACTION_TURN_OFF"];
186 ACTIVE -> OFF ["label"="PM_DEVICE_ACTION_TURN_OFF"];
191 This is entirely done by the power management subsystem. Instead, drivers are
192 responsible for implementing any hardware-specific tasks needed to handle state
195 Device Model with Power Management Support
199 details on how these macros are used. A driver which implements device power
201 power management implementation.
204 power management resources required by a driver. These macros allocate the
205 driver-specific state which is required by the power management subsystem.
210 to initialize the power management field in each :c:struct:`device`.
212 Here is some example code showing how to implement device power management
215 .. code-block:: c
233 * powered on the device, used when the power
240 * power off the device, used when the power
246 return -ENOTSUP;
258 .. _pm-device-shell:
263 Power management actions can be triggered from shell commands for testing
265 option and issue a ``pm`` command on a device from the shell, for example:
267 .. code-block:: console
270 - buttons (active)
274 - buttons (suspended)
276 To print the power management state of a device, enable
280 .. code-block:: console
284 - i2c@40003000 (active)
285 - buttons (active, usage=1)
286 - leds (READY)
292 .. _pm-device-busy:
297 When the system is idle and the SoC is going to sleep, the power management
298 subsystem can suspend devices, as described in :ref:`pm-device-system-pm`. This
306 the system will not do power management on it. After the device is no
310 .. _pm-device-constraint:
312 Device Power Management X System Power Management
315 When managing power in embedded systems, it's crucial to understand
316 the interplay between device power state and the overall system power
317 state. Some devices may have dependencies on the system power
318 state. For example, certain low-power states of the SoC might not
319 supply power to peripheral devices, leading to problems if the device
323 To avoid this sort of problem, devices must :ref:`get and release lock <pm-policy-power-states>`
324 power states that cause power loss during an operation.
326 Zephyr provides a mechanism for devices to declare which power states cause power
327 loss and an API that automatically get and put lock on them. This feature is
331 states cause power loss. In the following example, device ``test_dev``
332 says that power states ``state1`` and ``state2`` cause power loss.
334 .. code-block:: devicetree
336 power-states {
338 compatible = "zephyr,power-state";
339 power-state-name = "suspend-to-idle";
340 min-residency-us = <10000>;
341 exit-latency-us = <100>;
345 compatible = "zephyr,power-state";
346 power-state-name = "standby";
347 min-residency-us = <20000>;
348 exit-latency-us = <200>;
352 compatible = "zephyr,power-state";
353 power-state-name = "suspend-to-ram";
354 min-residency-us = <50000>;
355 exit-latency-us = <500>;
359 compatible = "zephyr,power-state";
360 power-state-name = "suspend-to-ram";
366 compatible = "test-device-pm";
368 zephyr,disabling-power-states = <&state1 &state2>;
375 .. code-block:: C
381 data->ongoing = false;
383 pm_policy_device_power_lock_put(data->self);
388 struct test_driver_data *data = dev->data;
390 data->ongoing = true;
395 * make only state0 (suspend-to-idle) will be used.
397 k_timer_start(&data->timer, K_MSEC(500), K_NO_WAIT);
405 this feature on a device dynamically using
408 This property can be set on device declaring the property ``wakeup-source`` in
412 .. code-block:: devicetree
415 compatible = "ti,cc13xx-cc26xx-gpio";
420 gpio-controller;
421 wakeup-source;
422 #gpio-cells = <2>;
431 This property is **only** used by the system power management to identify
439 Some helpful examples showing device power management features: