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#
7 title: Generic PM domains
10   - Rafael J. Wysocki <rjw@rjwysocki.net>
11   - Kevin Hilman <khilman@kernel.org>
12   - Ulf Hansson <ulf.hansson@linaro.org>
15   System on chip designs are often divided into multiple PM domains that can be
16   used for power gating of selected IP blocks for power saving by reduced leakage
20   their PM domains provided by PM domain providers. A PM domain provider can be
22   domains. A consumer node can refer to the provider by a phandle and a set of
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
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
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
48       the power domains provided by the provider have identical OPP tables,
52   "#power-domain-cells":
56       domains (e.g. power controllers), but can be any value as specified
59   power-domains:
61       A phandle and PM domain specifier as defined by bindings of the power
62       controller specified by phandle. Some power domains might be powered
63       from another power domain (or have other hardware specific
65       consumer binding is used. When provided, all domains created
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>;
99     // The nodes above define two power controllers: 'parent' and 'child'.
100     // Domains created by the 'child' power controller are subdomains of '0' power
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>;