tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
dt-bindings: power: Convert Generic Power Domain bindings to json-schema
Convert Generic Power Domain bindings to DT schema format using
json-schema.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
authored by
Krzysztof Kozlowski
and committed by
Rob Herring
5279a3d8
3afd6389
+149
-109
+1
-1
Documentation/devicetree/bindings/arm/arm,scmi.txt
+1
-1
Documentation/devicetree/bindings/arm/arm,scmi.txt
···
100
100
101
101
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
102
102
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
103
-
[2] Documentation/devicetree/bindings/power/power_domain.txt
103
+
[2] Documentation/devicetree/bindings/power/power-domain.yaml
104
104
[3] Documentation/devicetree/bindings/thermal/thermal.txt
105
105
[4] Documentation/devicetree/bindings/sram/sram.txt
106
106
[5] Documentation/devicetree/bindings/reset/reset.txt
+1
-1
Documentation/devicetree/bindings/arm/arm,scpi.txt
+1
-1
Documentation/devicetree/bindings/arm/arm,scpi.txt
···
110
110
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
111
111
[2] Documentation/devicetree/bindings/thermal/thermal.txt
112
112
[3] Documentation/devicetree/bindings/sram/sram.txt
113
-
[4] Documentation/devicetree/bindings/power/power_domain.txt
113
+
[4] Documentation/devicetree/bindings/power/power-domain.yaml
114
114
115
115
Example:
116
116
+1
-1
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+1
-1
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
···
124
124
CONFIG settings.
125
125
126
126
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
127
-
[2] Documentation/devicetree/bindings/power/power_domain.txt
127
+
[2] Documentation/devicetree/bindings/power/power-domain.yaml
128
128
[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
129
129
130
130
RTC bindings based on SCU Message Protocol
+1
-1
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+1
-1
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
···
59
59
power-managed through Module Standby should refer to the CPG device
60
60
node in their "power-domains" property, as documented by the generic PM
61
61
Domain bindings in
62
-
Documentation/devicetree/bindings/power/power_domain.txt.
62
+
Documentation/devicetree/bindings/power/power-domain.yaml.
63
63
64
64
- #reset-cells: Must be 1
65
65
- The single reset specifier cell must be the module number, as defined
+1
-1
Documentation/devicetree/bindings/clock/ti/davinci/psc.txt
+1
-1
Documentation/devicetree/bindings/clock/ti/davinci/psc.txt
+1
-1
Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
+1
-1
Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
+1
-1
Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt
+1
-1
Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt
+1
-1
Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
+1
-1
Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
···
19
19
- ipg
20
20
21
21
The power domains are generic power domain providers as documented in
22
-
Documentation/devicetree/bindings/power/power_domain.txt. They are described as
22
+
Documentation/devicetree/bindings/power/power-domain.yaml. They are described as
23
23
subnodes of the power gating controller 'pgc' node of the GPC and should
24
24
contain the following:
25
25
+1
-1
Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
+1
-1
Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
···
17
17
18
18
Power domains contained within GPC node are generic power domain
19
19
providers, documented in
20
-
Documentation/devicetree/bindings/power/power_domain.txt, which are
20
+
Documentation/devicetree/bindings/power/power-domain.yaml, which are
21
21
described as subnodes of the power gating controller 'pgc' node,
22
22
which, in turn, is expected to contain the following:
23
23
+133
Documentation/devicetree/bindings/power/power-domain.yaml
+133
Documentation/devicetree/bindings/power/power-domain.yaml
···
1
+
# SPDX-License-Identifier: GPL-2.0
2
+
%YAML 1.2
3
+
---
4
+
$id: http://devicetree.org/schemas/power/power-domain.yaml#
5
+
$schema: http://devicetree.org/meta-schemas/core.yaml#
6
+
7
+
title: Generic PM domains
8
+
9
+
maintainers:
10
+
- Rafael J. Wysocki <rjw@rjwysocki.net>
11
+
- Kevin Hilman <khilman@kernel.org>
12
+
- Ulf Hansson <ulf.hansson@linaro.org>
13
+
14
+
description: |+
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
17
+
current.
18
+
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
21
+
represented by any node in the device tree and can provide one or more PM
22
+
domains. A consumer node can refer to the provider by a phandle and a set of
23
+
phandle arguments (so called PM domain specifiers) of length specified by the
24
+
\#power-domain-cells property in the PM domain provider node.
25
+
26
+
properties:
27
+
$nodename:
28
+
pattern: "^(power-controller|power-domain)(@.*)?$"
29
+
30
+
domain-idle-states:
31
+
$ref: /schemas/types.yaml#/definitions/phandle-array
32
+
description:
33
+
A phandle of an idle-state that shall be soaked into a generic domain
34
+
power state. The idle state definitions are compatible with
35
+
domain-idle-state specified in
36
+
Documentation/devicetree/bindings/power/domain-idle-state.txt
37
+
phandles that are not compatible with domain-idle-state will be ignored.
38
+
The domain-idle-state property reflects the idle state of this PM domain
39
+
and not the idle states of the devices or sub-domains in the PM domain.
40
+
Devices and sub-domains have their own idle-states independent
41
+
of the parent domain's idle states. In the absence of this property,
42
+
the domain would be considered as capable of being powered-on
43
+
or powered-off.
44
+
45
+
operating-points-v2:
46
+
$ref: /schemas/types.yaml#/definitions/phandle-array
47
+
description:
48
+
Phandles to the OPP tables of power domains provided by a power domain
49
+
provider. If the provider provides a single power domain only or all
50
+
the power domains provided by the provider have identical OPP tables,
51
+
then this shall contain a single phandle. Refer to ../opp/opp.txt
52
+
for more information.
53
+
54
+
"#power-domain-cells":
55
+
description:
56
+
Number of cells in a PM domain specifier. Typically 0 for nodes
57
+
representing a single PM domain and 1 for nodes providing multiple PM
58
+
domains (e.g. power controllers), but can be any value as specified
59
+
by device tree binding documentation of particular provider.
60
+
61
+
power-domains:
62
+
description:
63
+
A phandle and PM domain specifier as defined by bindings of the power
64
+
controller specified by phandle. Some power domains might be powered
65
+
from another power domain (or have other hardware specific
66
+
dependencies). For representing such dependency a standard PM domain
67
+
consumer binding is used. When provided, all domains created
68
+
by the given provider should be subdomains of the domain specified
69
+
by this binding.
70
+
71
+
required:
72
+
- "#power-domain-cells"
73
+
74
+
examples:
75
+
- |
76
+
power: power-controller@12340000 {
77
+
compatible = "foo,power-controller";
78
+
reg = <0x12340000 0x1000>;
79
+
#power-domain-cells = <1>;
80
+
};
81
+
82
+
// The node above defines a power controller that is a PM domain provider and
83
+
// expects one cell as its phandle argument.
84
+
85
+
- |
86
+
parent2: power-controller@12340000 {
87
+
compatible = "foo,power-controller";
88
+
reg = <0x12340000 0x1000>;
89
+
#power-domain-cells = <1>;
90
+
};
91
+
92
+
child2: power-controller@12341000 {
93
+
compatible = "foo,power-controller";
94
+
reg = <0x12341000 0x1000>;
95
+
power-domains = <&parent2 0>;
96
+
#power-domain-cells = <1>;
97
+
};
98
+
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.
102
+
103
+
- |
104
+
parent3: power-controller@12340000 {
105
+
compatible = "foo,power-controller";
106
+
reg = <0x12340000 0x1000>;
107
+
#power-domain-cells = <0>;
108
+
domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
109
+
};
110
+
111
+
child3: power-controller@12341000 {
112
+
compatible = "foo,power-controller";
113
+
reg = <0x12341000 0x1000>;
114
+
power-domains = <&parent3>;
115
+
#power-domain-cells = <0>;
116
+
domain-idle-states = <&DOMAIN_PWR_DN>;
117
+
};
118
+
119
+
DOMAIN_RET: state@0 {
120
+
compatible = "domain-idle-state";
121
+
reg = <0x0 0x0>;
122
+
entry-latency-us = <1000>;
123
+
exit-latency-us = <2000>;
124
+
min-residency-us = <10000>;
125
+
};
126
+
127
+
DOMAIN_PWR_DN: state@1 {
128
+
compatible = "domain-idle-state";
129
+
reg = <0x1 0x0>;
130
+
entry-latency-us = <5000>;
131
+
exit-latency-us = <8000>;
132
+
min-residency-us = <7000>;
133
+
};
+1
-94
Documentation/devicetree/bindings/power/power_domain.txt
Documentation/devicetree/bindings/power/power-domain.txt
+1
-94
Documentation/devicetree/bindings/power/power_domain.txt
Documentation/devicetree/bindings/power/power-domain.txt
···
13
13
14
14
==PM domain providers==
15
15
16
-
Required properties:
17
-
- #power-domain-cells : Number of cells in a PM domain specifier;
18
-
Typically 0 for nodes representing a single PM domain and 1 for nodes
19
-
providing multiple PM domains (e.g. power controllers), but can be any value
20
-
as specified by device tree binding documentation of particular provider.
21
-
22
-
Optional properties:
23
-
- power-domains : A phandle and PM domain specifier as defined by bindings of
24
-
the power controller specified by phandle.
25
-
Some power domains might be powered from another power domain (or have
26
-
other hardware specific dependencies). For representing such dependency
27
-
a standard PM domain consumer binding is used. When provided, all domains
28
-
created by the given provider should be subdomains of the domain
29
-
specified by this binding. More details about power domain specifier are
30
-
available in the next section.
31
-
32
-
- domain-idle-states : A phandle of an idle-state that shall be soaked into a
33
-
generic domain power state. The idle state definitions are
34
-
compatible with domain-idle-state specified in [1]. phandles
35
-
that are not compatible with domain-idle-state will be
36
-
ignored.
37
-
The domain-idle-state property reflects the idle state of this PM domain and
38
-
not the idle states of the devices or sub-domains in the PM domain. Devices
39
-
and sub-domains have their own idle-states independent of the parent
40
-
domain's idle states. In the absence of this property, the domain would be
41
-
considered as capable of being powered-on or powered-off.
42
-
43
-
- operating-points-v2 : Phandles to the OPP tables of power domains provided by
44
-
a power domain provider. If the provider provides a single power domain only
45
-
or all the power domains provided by the provider have identical OPP tables,
46
-
then this shall contain a single phandle. Refer to ../opp/opp.txt for more
47
-
information.
48
-
49
-
Example:
50
-
51
-
power: power-controller@12340000 {
52
-
compatible = "foo,power-controller";
53
-
reg = <0x12340000 0x1000>;
54
-
#power-domain-cells = <1>;
55
-
};
56
-
57
-
The node above defines a power controller that is a PM domain provider and
58
-
expects one cell as its phandle argument.
59
-
60
-
Example 2:
61
-
62
-
parent: power-controller@12340000 {
63
-
compatible = "foo,power-controller";
64
-
reg = <0x12340000 0x1000>;
65
-
#power-domain-cells = <1>;
66
-
};
67
-
68
-
child: power-controller@12341000 {
69
-
compatible = "foo,power-controller";
70
-
reg = <0x12341000 0x1000>;
71
-
power-domains = <&parent 0>;
72
-
#power-domain-cells = <1>;
73
-
};
74
-
75
-
The nodes above define two power controllers: 'parent' and 'child'.
76
-
Domains created by the 'child' power controller are subdomains of '0' power
77
-
domain provided by the 'parent' power controller.
78
-
79
-
Example 3:
80
-
parent: power-controller@12340000 {
81
-
compatible = "foo,power-controller";
82
-
reg = <0x12340000 0x1000>;
83
-
#power-domain-cells = <0>;
84
-
domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
85
-
};
86
-
87
-
child: power-controller@12341000 {
88
-
compatible = "foo,power-controller";
89
-
reg = <0x12341000 0x1000>;
90
-
power-domains = <&parent>;
91
-
#power-domain-cells = <0>;
92
-
domain-idle-states = <&DOMAIN_PWR_DN>;
93
-
};
94
-
95
-
DOMAIN_RET: state@0 {
96
-
compatible = "domain-idle-state";
97
-
reg = <0x0>;
98
-
entry-latency-us = <1000>;
99
-
exit-latency-us = <2000>;
100
-
min-residency-us = <10000>;
101
-
};
102
-
103
-
DOMAIN_PWR_DN: state@1 {
104
-
compatible = "domain-idle-state";
105
-
reg = <0x1>;
106
-
entry-latency-us = <5000>;
107
-
exit-latency-us = <8000>;
108
-
min-residency-us = <7000>;
109
-
};
16
+
See power-domain.yaml.
110
17
111
18
==PM domain consumers==
112
19
+1
-1
Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
+1
-1
Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
···
29
29
30
30
Each of the PM domain nodes represents a PM domain, as documented by the
31
31
generic PM domain bindings in
32
-
Documentation/devicetree/bindings/power/power_domain.txt.
32
+
Documentation/devicetree/bindings/power/power-domain.yaml.
33
33
34
34
The nodes should be named by the real power area names, and thus their names
35
35
should be unique.
+1
-1
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
+1
-1
Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
+1
-1
Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
+1
-1
Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
···
26
26
system power. This node follows the power controller bindings[3].
27
27
28
28
[1] Documentation/devicetree/bindings/reset/reset.txt
29
-
[2] Documentation/devicetree/bindings/power/power_domain.txt
29
+
[2] Documentation/devicetree/bindings/power/power-domain.yaml
30
30
[3] Documentation/devicetree/bindings/power/power-controller.txt
31
31
32
32
Example:
+1
-1
Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+1
-1
Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
···
8
8
domain control.
9
9
10
10
The driver implements the Generic PM domain bindings described in
11
-
power/power_domain.txt. It provides the power domains defined in
11
+
power/power-domain.yaml. It provides the power domains defined in
12
12
- include/dt-bindings/power/mt8173-power.h
13
13
- include/dt-bindings/power/mt6797-power.h
14
14
- include/dt-bindings/power/mt2701-power.h
+1
-1
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+1
-1
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
···
12
12
==============
13
13
The PM domain node represents the global PM domain managed by the PMMC, which
14
14
in this case is the implementation as documented by the generic PM domain
15
-
bindings in Documentation/devicetree/bindings/power/power_domain.txt. Because
15
+
bindings in Documentation/devicetree/bindings/power/power-domain.yaml. Because
16
16
this relies on the TI SCI protocol to communicate with the PMMC it must be a
17
17
child of the pmmc node.
18
18
+1
-1
MAINTAINERS
+1
-1
MAINTAINERS
···
6882
6882
S: Supported
6883
6883
F: drivers/base/power/domain*.c
6884
6884
F: include/linux/pm_domain.h
6885
-
F: Documentation/devicetree/bindings/power/power_domain.txt
6885
+
F: Documentation/devicetree/bindings/power/power-domain*
6886
6886
6887
6887
GENERIC RESISTIVE TOUCHSCREEN ADC DRIVER
6888
6888
M: Eugen Hristev <eugen.hristev@microchip.com>