bindings/power/power-domain.yaml

1 # SPDX-License-Identifier: GPL-2.0
3 ---
4 $id: http://devicetree.org/schemas/power/power-domain.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10   - Rafael J. Wysocki <rjw@rjwysocki.net>
11   - Kevin Hilman <khilman@kernel.org>
12   - Ulf Hansson <ulf.hansson@linaro.org>
19   This device tree binding can be used to bind PM domain consumer devices with
20   their PM domains provided by PM domain providers. A PM domain provider can be
23   phandle arguments (so called PM domain specifiers) of length specified by the
24   \#power-domain-cells property in the PM domain provider node.
28     pattern: "^(power-controller|power-domain)([@-].*)?$"
30   domain-idle-states:
31     $ref: /schemas/types.yaml#/definitions/phandle-array
33       Phandles of idle states that defines the available states for the
34       power-domain provider. The idle state definitions are compatible with the
35       domain-idle-state bindings, specified in ./domain-idle-state.yaml.
37       Note that, the domain-idle-state property reflects the idle states of this
38       PM domain and not the idle states of the devices or sub-domains in the PM
39       domain. Devices and sub-domains have their own idle states independent of
40       the parent domain's idle states. In the absence of this property, the
41       domain would be considered as capable of being powered-on or powered-off.
43   operating-points-v2:
44     $ref: /schemas/types.yaml#/definitions/phandle-array
46       Phandles to the OPP tables of power domains provided by a power domain
47       provider. If the provider provides a single power domain only or all
52   "#power-domain-cells":
54       Number of cells in a PM domain specifier. Typically 0 for nodes
55       representing a single PM domain and 1 for nodes providing multiple PM
59   power-domains:
61       A phandle and PM domain specifier as defined by bindings of the power
63       from another power domain (or have other hardware specific
64       dependencies). For representing such dependency a standard PM domain
66       by the given provider should be subdomains of the domain specified
70   - "#power-domain-cells"
75   - |
76     power: power-controller@12340000 {
77         compatible = "foo,power-controller";
79         #power-domain-cells = <1>;
82     // The node above defines a power controller that is a PM domain provider and
85   - |
86     parent2: power-controller@12340000 {
87         compatible = "foo,power-controller";
89         #power-domain-cells = <1>;
92     child2: power-controller@12341000 {
93         compatible = "foo,power-controller";
95         power-domains = <&parent2 0>;
96         #power-domain-cells = <1>;
101     // domain provided by the 'parent' power controller.
103   - |
104     parent3: power-controller@12340000 {
105         compatible = "foo,power-controller";
107         #power-domain-cells = <0>;
108         domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
111     child3: power-controller@12341000 {
112         compatible = "foo,power-controller";
114         power-domains = <&parent3>;
115         #power-domain-cells = <0>;
116         domain-idle-states = <&DOMAIN_PWR_DN>;
119     domain-idle-states {
120         DOMAIN_RET: domain-retention {
121             compatible = "domain-idle-state";
122             entry-latency-us = <1000>;
123             exit-latency-us = <2000>;
124             min-residency-us = <10000>;
127         DOMAIN_PWR_DN: domain-pwr-dn {
128             compatible = "domain-idle-state";
129             entry-latency-us = <5000>;
130             exit-latency-us = <8000>;
131             min-residency-us = <7000>;