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>

1 files changed, 0 insertions, 205 deletions

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
deleted file mode 100644
index 8f8b25a24b8f..000000000000
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ /dev/null
@@ -1,205 +0,0 @@
-* 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