[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
[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:
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
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
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
- .../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>
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:
---------------------
- 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:
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:
==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==
--- /dev/null
+# 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>;
+ };
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.
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 ==
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:
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
==============
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.
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>
projects / thirdparty / kernel / linux.git / commitdiff
