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>
This commit is contained in:
parent
3afd6389f3
commit
5279a3d8be
@ -100,7 +100,7 @@ Required sub-node properties:
|
||||
|
||||
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
[2] Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
[3] Documentation/devicetree/bindings/thermal/thermal.txt
|
||||
[4] Documentation/devicetree/bindings/sram/sram.txt
|
||||
[5] Documentation/devicetree/bindings/reset/reset.txt
|
||||
|
@ -110,7 +110,7 @@ Required properties:
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/thermal/thermal.txt
|
||||
[3] Documentation/devicetree/bindings/sram/sram.txt
|
||||
[4] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
[4] Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -124,7 +124,7 @@ Required properties for Pinctrl sub nodes:
|
||||
CONFIG settings.
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
[2] Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
|
||||
|
||||
RTC bindings based on SCU Message Protocol
|
||||
|
@ -59,7 +59,7 @@ Required Properties:
|
||||
power-managed through Module Standby should refer to the CPG device
|
||||
node in their "power-domains" property, as documented by the generic PM
|
||||
Domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
Documentation/devicetree/bindings/power/power-domain.yaml.
|
||||
|
||||
- #reset-cells: Must be 1
|
||||
- The single reset specifier cell must be the module number, as defined
|
||||
|
@ -67,5 +67,5 @@ Examples:
|
||||
|
||||
Also see:
|
||||
- Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
- Documentation/devicetree/bindings/power/power_domain.txt
|
||||
- Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
- Documentation/devicetree/bindings/reset/reset.txt
|
||||
|
@ -32,7 +32,7 @@ implemented by this node:
|
||||
|
||||
- .../clock/clock-bindings.txt
|
||||
- <dt-bindings/clock/tegra186-clock.h>
|
||||
- ../power/power_domain.txt
|
||||
- ../power/power-domain.yaml
|
||||
- <dt-bindings/power/tegra186-powergate.h>
|
||||
- .../reset/reset.txt
|
||||
- <dt-bindings/reset/tegra186-reset.h>
|
||||
|
@ -10,7 +10,7 @@ The Video Processing Unit power domain is controlled by this power controller,
|
||||
but the domain requires some external resources to meet the correct power
|
||||
sequences.
|
||||
The bindings must respect the power domain bindings as described in the file
|
||||
power_domain.txt
|
||||
power-domain.yaml
|
||||
|
||||
Device Tree Bindings:
|
||||
---------------------
|
||||
|
@ -19,7 +19,7 @@ Required properties:
|
||||
- ipg
|
||||
|
||||
The power domains are generic power domain providers as documented in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt. They are described as
|
||||
Documentation/devicetree/bindings/power/power-domain.yaml. They are described as
|
||||
subnodes of the power gating controller 'pgc' node of the GPC and should
|
||||
contain the following:
|
||||
|
||||
|
@ -17,7 +17,7 @@ Required properties:
|
||||
|
||||
Power domains contained within GPC node are generic power domain
|
||||
providers, documented in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt, which are
|
||||
Documentation/devicetree/bindings/power/power-domain.yaml, which are
|
||||
described as subnodes of the power gating controller 'pgc' node,
|
||||
which, in turn, is expected to contain the following:
|
||||
|
||||
|
@ -13,100 +13,7 @@ phandle arguments (so called PM domain specifiers) of length specified by the
|
||||
|
||||
==PM domain providers==
|
||||
|
||||
Required properties:
|
||||
- #power-domain-cells : Number of cells in a PM domain specifier;
|
||||
Typically 0 for nodes representing a single PM domain and 1 for nodes
|
||||
providing multiple PM domains (e.g. power controllers), but can be any value
|
||||
as specified by device tree binding documentation of particular provider.
|
||||
|
||||
Optional properties:
|
||||
- power-domains : A phandle and PM domain specifier as defined by bindings of
|
||||
the power controller specified by phandle.
|
||||
Some power domains might be powered from another power domain (or have
|
||||
other hardware specific dependencies). For representing such dependency
|
||||
a standard PM domain consumer binding is used. When provided, all domains
|
||||
created by the given provider should be subdomains of the domain
|
||||
specified by this binding. More details about power domain specifier are
|
||||
available in the next section.
|
||||
|
||||
- domain-idle-states : A phandle of an idle-state that shall be soaked into a
|
||||
generic domain power state. The idle state definitions are
|
||||
compatible with domain-idle-state specified in [1]. phandles
|
||||
that are not compatible with domain-idle-state will be
|
||||
ignored.
|
||||
The domain-idle-state property reflects the idle state of this PM domain and
|
||||
not the idle states of the devices or sub-domains in the PM domain. Devices
|
||||
and sub-domains have their own idle-states independent of the parent
|
||||
domain's idle states. In the absence of this property, the domain would be
|
||||
considered as capable of being powered-on or powered-off.
|
||||
|
||||
- operating-points-v2 : Phandles to the OPP tables of power domains provided by
|
||||
a power domain provider. If the provider provides a single power domain only
|
||||
or all the power domains provided by the provider have identical OPP tables,
|
||||
then this shall contain a single phandle. Refer to ../opp/opp.txt for more
|
||||
information.
|
||||
|
||||
Example:
|
||||
|
||||
power: power-controller@12340000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12340000 0x1000>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
The node above defines a power controller that is a PM domain provider and
|
||||
expects one cell as its phandle argument.
|
||||
|
||||
Example 2:
|
||||
|
||||
parent: power-controller@12340000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12340000 0x1000>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
child: power-controller@12341000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12341000 0x1000>;
|
||||
power-domains = <&parent 0>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
The nodes above define two power controllers: 'parent' and 'child'.
|
||||
Domains created by the 'child' power controller are subdomains of '0' power
|
||||
domain provided by the 'parent' power controller.
|
||||
|
||||
Example 3:
|
||||
parent: power-controller@12340000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12340000 0x1000>;
|
||||
#power-domain-cells = <0>;
|
||||
domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
|
||||
};
|
||||
|
||||
child: power-controller@12341000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12341000 0x1000>;
|
||||
power-domains = <&parent>;
|
||||
#power-domain-cells = <0>;
|
||||
domain-idle-states = <&DOMAIN_PWR_DN>;
|
||||
};
|
||||
|
||||
DOMAIN_RET: state@0 {
|
||||
compatible = "domain-idle-state";
|
||||
reg = <0x0>;
|
||||
entry-latency-us = <1000>;
|
||||
exit-latency-us = <2000>;
|
||||
min-residency-us = <10000>;
|
||||
};
|
||||
|
||||
DOMAIN_PWR_DN: state@1 {
|
||||
compatible = "domain-idle-state";
|
||||
reg = <0x1>;
|
||||
entry-latency-us = <5000>;
|
||||
exit-latency-us = <8000>;
|
||||
min-residency-us = <7000>;
|
||||
};
|
||||
See power-domain.yaml.
|
||||
|
||||
==PM domain consumers==
|
||||
|
133
Documentation/devicetree/bindings/power/power-domain.yaml
Normal file
133
Documentation/devicetree/bindings/power/power-domain.yaml
Normal file
@ -0,0 +1,133 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/power/power-domain.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Generic PM domains
|
||||
|
||||
maintainers:
|
||||
- Rafael J. Wysocki <rjw@rjwysocki.net>
|
||||
- Kevin Hilman <khilman@kernel.org>
|
||||
- Ulf Hansson <ulf.hansson@linaro.org>
|
||||
|
||||
description: |+
|
||||
System on chip designs are often divided into multiple PM domains that can be
|
||||
used for power gating of selected IP blocks for power saving by reduced leakage
|
||||
current.
|
||||
|
||||
This device tree binding can be used to bind PM domain consumer devices with
|
||||
their PM domains provided by PM domain providers. A PM domain provider can be
|
||||
represented by any node in the device tree and can provide one or more PM
|
||||
domains. A consumer node can refer to the provider by a phandle and a set of
|
||||
phandle arguments (so called PM domain specifiers) of length specified by the
|
||||
\#power-domain-cells property in the PM domain provider node.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^(power-controller|power-domain)(@.*)?$"
|
||||
|
||||
domain-idle-states:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
A phandle of an idle-state that shall be soaked into a generic domain
|
||||
power state. The idle state definitions are compatible with
|
||||
domain-idle-state specified in
|
||||
Documentation/devicetree/bindings/power/domain-idle-state.txt
|
||||
phandles that are not compatible with domain-idle-state will be ignored.
|
||||
The domain-idle-state property reflects the idle state of this PM domain
|
||||
and not the idle states of the devices or sub-domains in the PM domain.
|
||||
Devices and sub-domains have their own idle-states independent
|
||||
of the parent domain's idle states. In the absence of this property,
|
||||
the domain would be considered as capable of being powered-on
|
||||
or powered-off.
|
||||
|
||||
operating-points-v2:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
Phandles to the OPP tables of power domains provided by a power domain
|
||||
provider. If the provider provides a single power domain only or all
|
||||
the power domains provided by the provider have identical OPP tables,
|
||||
then this shall contain a single phandle. Refer to ../opp/opp.txt
|
||||
for more information.
|
||||
|
||||
"#power-domain-cells":
|
||||
description:
|
||||
Number of cells in a PM domain specifier. Typically 0 for nodes
|
||||
representing a single PM domain and 1 for nodes providing multiple PM
|
||||
domains (e.g. power controllers), but can be any value as specified
|
||||
by device tree binding documentation of particular provider.
|
||||
|
||||
power-domains:
|
||||
description:
|
||||
A phandle and PM domain specifier as defined by bindings of the power
|
||||
controller specified by phandle. Some power domains might be powered
|
||||
from another power domain (or have other hardware specific
|
||||
dependencies). For representing such dependency a standard PM domain
|
||||
consumer binding is used. When provided, all domains created
|
||||
by the given provider should be subdomains of the domain specified
|
||||
by this binding.
|
||||
|
||||
required:
|
||||
- "#power-domain-cells"
|
||||
|
||||
examples:
|
||||
- |
|
||||
power: power-controller@12340000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12340000 0x1000>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
// The node above defines a power controller that is a PM domain provider and
|
||||
// expects one cell as its phandle argument.
|
||||
|
||||
- |
|
||||
parent2: power-controller@12340000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12340000 0x1000>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
child2: power-controller@12341000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12341000 0x1000>;
|
||||
power-domains = <&parent2 0>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
// The nodes above define two power controllers: 'parent' and 'child'.
|
||||
// Domains created by the 'child' power controller are subdomains of '0' power
|
||||
// domain provided by the 'parent' power controller.
|
||||
|
||||
- |
|
||||
parent3: power-controller@12340000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12340000 0x1000>;
|
||||
#power-domain-cells = <0>;
|
||||
domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
|
||||
};
|
||||
|
||||
child3: power-controller@12341000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12341000 0x1000>;
|
||||
power-domains = <&parent3>;
|
||||
#power-domain-cells = <0>;
|
||||
domain-idle-states = <&DOMAIN_PWR_DN>;
|
||||
};
|
||||
|
||||
DOMAIN_RET: state@0 {
|
||||
compatible = "domain-idle-state";
|
||||
reg = <0x0 0x0>;
|
||||
entry-latency-us = <1000>;
|
||||
exit-latency-us = <2000>;
|
||||
min-residency-us = <10000>;
|
||||
};
|
||||
|
||||
DOMAIN_PWR_DN: state@1 {
|
||||
compatible = "domain-idle-state";
|
||||
reg = <0x1 0x0>;
|
||||
entry-latency-us = <5000>;
|
||||
exit-latency-us = <8000>;
|
||||
min-residency-us = <7000>;
|
||||
};
|
@ -29,7 +29,7 @@ Optional nodes:
|
||||
|
||||
Each of the PM domain nodes represents a PM domain, as documented by the
|
||||
generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
Documentation/devicetree/bindings/power/power-domain.yaml.
|
||||
|
||||
The nodes should be named by the real power area names, and thus their names
|
||||
should be unique.
|
||||
|
@ -4,7 +4,7 @@ Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
|
||||
The binding for zynqmp-power-controller follow the common
|
||||
generic PM domain binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
[1] Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
|
||||
== Zynq MPSoC Generic PM Domain Node ==
|
||||
|
||||
|
@ -26,7 +26,7 @@ Optional properties:
|
||||
system power. This node follows the power controller bindings[3].
|
||||
|
||||
[1] Documentation/devicetree/bindings/reset/reset.txt
|
||||
[2] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
[2] Documentation/devicetree/bindings/power/power-domain.yaml
|
||||
[3] Documentation/devicetree/bindings/power/power-controller.txt
|
||||
|
||||
Example:
|
||||
|
@ -8,7 +8,7 @@ The System Power Manager (SPM) inside the SCPSYS is for the MTCMOS power
|
||||
domain control.
|
||||
|
||||
The driver implements the Generic PM domain bindings described in
|
||||
power/power_domain.txt. It provides the power domains defined in
|
||||
power/power-domain.yaml. It provides the power domains defined in
|
||||
- include/dt-bindings/power/mt8173-power.h
|
||||
- include/dt-bindings/power/mt6797-power.h
|
||||
- include/dt-bindings/power/mt2701-power.h
|
||||
|
@ -12,7 +12,7 @@ PM Domain Node
|
||||
==============
|
||||
The PM domain node represents the global PM domain managed by the PMMC, which
|
||||
in this case is the implementation as documented by the generic PM domain
|
||||
bindings in Documentation/devicetree/bindings/power/power_domain.txt. Because
|
||||
bindings in Documentation/devicetree/bindings/power/power-domain.yaml. Because
|
||||
this relies on the TI SCI protocol to communicate with the PMMC it must be a
|
||||
child of the pmmc node.
|
||||
|
||||
|
@ -6882,7 +6882,7 @@ L: linux-pm@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/base/power/domain*.c
|
||||
F: include/linux/pm_domain.h
|
||||
F: Documentation/devicetree/bindings/power/power_domain.txt
|
||||
F: Documentation/devicetree/bindings/power/power-domain*
|
||||
|
||||
GENERIC RESISTIVE TOUCHSCREEN ADC DRIVER
|
||||
M: Eugen Hristev <eugen.hristev@microchip.com>
|
||||
|
Loading…
Reference in New Issue
Block a user