Lines Matching full:device
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
24 device drivers, subsystems, and applications. While device drivers
26 devices, the decision to suspend or resume a device can also be
29 Each layer—device drivers, subsystems, and applications—can operate
32 to suspend or resume a device.
34 - **Device drivers** are responsible for managing the
38 :ref:`device runtime power management APIs <device_runtime_apis>` provided
42 and network, can also influence device power management.
49 - **Applications** running on Zephyr can impact device
51 requirements regarding device usage and power consumption. For
55 Coordination between device drivers, subsystems, and applications is
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
60 the device remains in an active state until the operations are
63 When using this Device Runtime Power Management, the System Power
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
78 When using this method, device power management is mostly done inside
82 subsystem will check if the selected low power state triggers device power
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
104 zephyr,pm-device-disabled;
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
124 resuming. This implementation is reasonably simpler than device runtime
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
144 :kconfig:option:`CONFIG_PM_NEED_ALL_DEVICES_IDLE` is set and a device
152 Device Power Management States
155 The power management subsystem defines device states in
157 a particular device. It is important to emphasize that, although the
158 state is tracked by the subsystem, it is the responsibility of each device driver
159 to handle device actions(:c:enum:`pm_device_action`) which change device state.
165 :caption: Device actions x states
190 As mentioned above, device drivers do not directly change between these states.
195 Device Model with Power Management Support
199 details on how these macros are used. A driver which implements device power
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
213 support in a device driver.
219 static int dummy_driver_pm_action(const struct device *dev,
224 /* suspend the device */
228 /* resume the device */
233 * powered on the device, used when the power
234 * domain this device belongs is resumed.
240 * power off the device, used when the power
241 * domain this device belongs is suspended.
258 .. _pm-device-shell:
265 option and issue a ``pm`` command on a device from the shell, for example:
269 uart:~$ device list
272 uart:~$ device list
276 To print the power management state of a device, enable
277 :kconfig:option:`CONFIG_DEVICE_SHELL` and use the ``device list`` command, for
282 uart:~$ device list
292 .. _pm-device-busy:
298 subsystem can suspend devices, as described in :ref:`pm-device-system-pm`. This
299 can cause device hardware to lose some states. Suspending a device which is in
302 transactions by indicating to the kernel that the device is in the middle of an
305 When :c:func:`pm_device_busy_set` is called, the device is marked as busy and
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
316 the interplay between device power state and the overall system power
319 supply power to peripheral devices, leading to problems if the device
331 states cause power loss. In the following example, device ``test_dev``
366 compatible = "test-device-pm";
386 void test_driver_async_operation(const struct device *dev)
404 When a device has such capability, applications can enable or disable
405 this feature on a device dynamically using
408 This property can be set on device declaring the property ``wakeup-source`` in
409 the device node in devicetree. For example, this devicetree fragment sets the
410 ``gpio0`` device as a "wakeup" source:
426 during the device initialization. Applications can enable this functionality
434 configuration required by the device to support it.
439 Some helpful examples showing device power management features: