[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:
--- /dev/null
+* Generic PM domains
+
+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.
+
+==PM domain providers==
+
+See power-domain.yaml.
+
+==PM domain consumers==
+
+Required properties:
+ - power-domains : A list of PM domain specifiers, as defined by bindings of
+ the power controller that is the PM domain provider.
+
+Optional properties:
+ - power-domain-names : A list of power domain name strings sorted in the same
+ order as the power-domains property. Consumers drivers will use
+ power-domain-names to match power domains with power-domains
+ specifiers.
+
+Example:
+
+ leaky-device@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&power 0>;
+ power-domain-names = "io";
+ };
+
+ leaky-device@12351000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12351000 0x1000>;
+ power-domains = <&power 0>, <&power 1> ;
+ power-domain-names = "io", "clk";
+ };
+
+The first example above defines a typical PM domain consumer device, which is
+located inside a PM domain with index 0 of a power controller represented by a
+node with the label "power".
+In the second example the consumer device are partitioned across two PM domains,
+the first with index 0 and the second with index 1, of a power controller that
+is represented by a node with the label "power".
+
+Optional properties:
+- required-opps: This contains phandle to an OPP node in another device's OPP
+ table. It may contain an array of phandles, where each phandle points to an
+ OPP of a different device. It should not contain multiple phandles to the OPP
+ nodes in the same OPP table. This specifies the minimum required OPP of the
+ device(s), whose OPP's phandle is present in this property, for the
+ functioning of the current device at the current OPP (where this property is
+ present).
+
+Example:
+- OPP table for domain provider that provides two domains.
+
+ domain0_opp_table: opp-table0 {
+ compatible = "operating-points-v2";
+
+ domain0_opp_0: opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <975000 970000 985000>;
+ };
+ domain0_opp_1: opp-1100000000 {
+ opp-hz = /bits/ 64 <1100000000>;
+ opp-microvolt = <1000000 980000 1010000>;
+ };
+ };
+
+ domain1_opp_table: opp-table1 {
+ compatible = "operating-points-v2";
+
+ domain1_opp_0: opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <975000 970000 985000>;
+ };
+ domain1_opp_1: opp-1300000000 {
+ opp-hz = /bits/ 64 <1300000000>;
+ opp-microvolt = <1000000 980000 1010000>;
+ };
+ };
+
+ power: power-controller@12340000 {
+ compatible = "foo,power-controller";
+ reg = <0x12340000 0x1000>;
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
+ };
+
+ leaky-device0@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&power 0>;
+ required-opps = <&domain0_opp_0>;
+ };
+
+ leaky-device1@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&power 1>;
+ required-opps = <&domain1_opp_1>;
+ };
+
+[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
--- /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>;
+ };
+++ /dev/null
-* Generic PM domains
-
-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.
-
-==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>;
- };
-
-==PM domain consumers==
-
-Required properties:
- - power-domains : A list of PM domain specifiers, as defined by bindings of
- the power controller that is the PM domain provider.
-
-Optional properties:
- - power-domain-names : A list of power domain name strings sorted in the same
- order as the power-domains property. Consumers drivers will use
- power-domain-names to match power domains with power-domains
- specifiers.
-
-Example:
-
- leaky-device@12350000 {
- compatible = "foo,i-leak-current";
- reg = <0x12350000 0x1000>;
- power-domains = <&power 0>;
- power-domain-names = "io";
- };
-
- leaky-device@12351000 {
- compatible = "foo,i-leak-current";
- reg = <0x12351000 0x1000>;
- power-domains = <&power 0>, <&power 1> ;
- power-domain-names = "io", "clk";
- };
-
-The first example above defines a typical PM domain consumer device, which is
-located inside a PM domain with index 0 of a power controller represented by a
-node with the label "power".
-In the second example the consumer device are partitioned across two PM domains,
-the first with index 0 and the second with index 1, of a power controller that
-is represented by a node with the label "power".
-
-Optional properties:
-- required-opps: This contains phandle to an OPP node in another device's OPP
- table. It may contain an array of phandles, where each phandle points to an
- OPP of a different device. It should not contain multiple phandles to the OPP
- nodes in the same OPP table. This specifies the minimum required OPP of the
- device(s), whose OPP's phandle is present in this property, for the
- functioning of the current device at the current OPP (where this property is
- present).
-
-Example:
-- OPP table for domain provider that provides two domains.
-
- domain0_opp_table: opp-table0 {
- compatible = "operating-points-v2";
-
- domain0_opp_0: opp-1000000000 {
- opp-hz = /bits/ 64 <1000000000>;
- opp-microvolt = <975000 970000 985000>;
- };
- domain0_opp_1: opp-1100000000 {
- opp-hz = /bits/ 64 <1100000000>;
- opp-microvolt = <1000000 980000 1010000>;
- };
- };
-
- domain1_opp_table: opp-table1 {
- compatible = "operating-points-v2";
-
- domain1_opp_0: opp-1200000000 {
- opp-hz = /bits/ 64 <1200000000>;
- opp-microvolt = <975000 970000 985000>;
- };
- domain1_opp_1: opp-1300000000 {
- opp-hz = /bits/ 64 <1300000000>;
- opp-microvolt = <1000000 980000 1010000>;
- };
- };
-
- power: power-controller@12340000 {
- compatible = "foo,power-controller";
- reg = <0x12340000 0x1000>;
- #power-domain-cells = <1>;
- operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
- };
-
- leaky-device0@12350000 {
- compatible = "foo,i-leak-current";
- reg = <0x12350000 0x1000>;
- power-domains = <&power 0>;
- required-opps = <&domain0_opp_0>;
- };
-
- leaky-device1@12350000 {
- compatible = "foo,i-leak-current";
- reg = <0x12350000 0x1000>;
- power-domains = <&power 1>;
- required-opps = <&domain1_opp_1>;
- };
-
-[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
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 / linux.git / commitdiff