Lines Matching +full:wakeup +full:- +full:and +full:- +full:sleep
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:
24 device drivers, subsystems, and applications. While device drivers
29 Each layer—device drivers, subsystems, and applications—can operate
34 - **Device drivers** are responsible for managing the
36 put devices into low-power states (suspend) when they are not in
37 use, and bring them back (resume) when needed. Drivers should use the
41 - **Subsystems**, such as sensors, file systems,
42 and network, can also influence device power management.
44 state and workload, allowing them to make informed decisions about
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
65 does not need to spend time suspending and resuming devices that are
68 For more information, see :ref:`pm-device-runtime`.
70 .. _pm-device-system-pm:
72 System-Managed Device Power Management
83 management and then suspend devices before changing state. The subsystem takes
86 from a sleep state, devices are resumed in the opposite order that they were
90 state and if it has set the property ``zephyr,pm-device-disabled``. Here is
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.
123 - Systems with no device requiring any blocking operations when suspending and
126 - For devices that can not make any power management decision and have to be
129 always active and should be suspended together with the SoC when requested by
132 It is important to emphasize that this method has drawbacks (see above) and
133 :ref:`Device Runtime Power Management <pm-device-runtime-pm>` is the
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
144 :kconfig:option:`CONFIG_PM_NEED_ALL_DEVICES_IDLE` is set and a device
150 state and devices are resumed by the first core that becomes active.
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"];
192 responsible for implementing any hardware-specific tasks needed to handle state
205 driver-specific state which is required by the power management subsystem.
215 .. code-block:: c
246 return -ENOTSUP;
258 .. _pm-device-shell:
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)
277 :kconfig:option:`CONFIG_DEVICE_SHELL` and use the ``device list`` command, for
280 .. code-block:: console
284 - i2c@40003000 (active)
285 - buttons (active, usage=1)
286 - leds (READY)
289 suspend and resume actions and it's currently active, ``buttons`` supports
290 runtime PM and it's currently active with one user.
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
303 operation and should not be suspended.
305 When :c:func:`pm_device_busy_set` is called, the device is marked as busy and
307 longer doing an operation and can be suspended, it should call
310 .. _pm-device-constraint:
316 the interplay between device power state and the overall system power
318 state. For example, certain low-power states of the SoC might not
321 maintain system stability and data integrity.
323 To avoid this sort of problem, devices must :ref:`get and release lock <pm-policy-power-states>`
327 loss and an API that automatically get and put lock on them. This feature is
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>;
372 :c:func:`pm_policy_device_power_lock_get` and release with
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;
394 * sleep state would be suitable but constraints will
395 * make only state0 (suspend-to-idle) will be used.
397 k_timer_start(&data->timer, K_MSEC(500), K_NO_WAIT);
400 Wakeup capability
403 Some devices are capable of waking the system up from a sleep state.
408 This property can be set on device declaring the property ``wakeup-source`` in
410 ``gpio0`` device as a "wakeup" source:
412 .. code-block:: devicetree
415 compatible = "ti,cc13xx-cc26xx-gpio";
420 gpio-controller;
421 wakeup-source;
422 #gpio-cells = <2>;
425 By default, "wakeup" capable devices do not have this functionality enabled