Lines Matching +full:pm +full:- +full:device +full:- +full:disabled
1 .. _pm-power-domain:
11 generic fashion. Application code that is using device A does not need to know
12 that device B is on the same power domain and should also be configured into a
25 .. _pm-domain-work-flow:
42 action -> devA [label="pm_device_get()"]
43 devA:se -> domain:n [label="pm_device_get()"]
45 domain -> devB [label="action_cb(PM_DEVICE_ACTION_TURN_ON)"]
46 domain:sw -> devA:sw [label="action_cb(PM_DEVICE_ACTION_TURN_ON)"]
50 ----------------------
55 only using device power management. To solve this problem, SoCs
63 ----------------------
77 In a first place, a device that acts as a power domain needs to
78 declare compatible with ``power-domain``. Taking
79 :ref:`pm-domain-work-flow` as example, the following code defines a
82 .. code-block:: devicetree
85 compatible = "power-domain";
89 A power domain needs to implement the PM action callback used by the
90 PM subsystem to turn devices on and off.
92 .. code-block:: c
94 static int mydomain_pm_action(const struct device *dev,
111 /* turn on the domain (e.g. setup control pins to disabled) */
119 return -ENOTSUP;
125 Devices belonging to this device can be declared referring it in the
126 ``power-domain`` node's property. The example below declares devices
129 .. code-block:: devicetree
132 compatible = "zephyr,gpio-emul";
133 gpio-controller;
134 power-domains = <&gpio_domain>;
138 compatible = "zephyr,gpio-emul";
139 gpio-controller;
140 power-domains = <&gpio_domain>;
144 state. These notifications are sent as actions in the device PM action
148 .. code-block:: c
150 static int mydev_pm_action(const struct device *dev,
155 /* suspend the device */
159 /* resume the device */
163 /* configure the device into low power mode */
167 /* prepare the device for power down */
171 return -ENOTSUP;
180 "wakeup" source if a device depending on it is used as "wakeup" source.
187 * :zephyr_file:`tests/subsys/pm/device_power_domains/`
188 * :zephyr_file:`tests/subsys/pm/power_domain/`