Message-Id: <132e9200102bf2f1175567f0862596d098363d9e.1487926924.git.viresh.kumar@linaro.org>
Date:   Fri, 24 Feb 2017 14:36:33 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Rafael Wysocki <rjw@...ysocki.net>, ulf.hansson@...aro.org,
        Kevin Hilman <khilman@...aro.org>
Cc:     linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Stephen Boyd <sboyd@...eaurora.org>,
        Nishanth Menon <nm@...com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        robh+dt@...nel.org, lina.iyer@...aro.org, rnayak@...eaurora.org,
        Viresh Kumar <viresh.kumar@...aro.org>,
        devicetree@...r.kernel.org
Subject: [PATCH V3 1/7] PM / Domains: Introduce "performance-states" binding

Some platforms have the capability to configure the performance state of
their power domains. The process of configuring the performance state is
pretty much platform dependent and we may need to work with a wide range
of configurables. For some platforms, like Qcom, it can be a positive
integer value alone, while in other cases it can be voltage levels, etc.

The power-domain framework until now was only designed for the idle
state management of the device and this needs to change in order to
reuse the power-domain framework for active state management of the
devices.

This patch adds DT bindings to describe the performance states of a
power domain. The power domain node needs to contain a
"performance-states" node, which itself is an array of per-state nodes.
Each per-state node represents individual performance state of a device.
Individual nodes are identified by their (mandatory) "reg" field. These
nodes can also contain an optional "domain-microvolt" property. More
properties can be added later on once we have more platforms using it.

If the consumers don't need the capability of switching to different
domain performance states at runtime, then they can simply define their
required domain performance state in their node directly using the
"domain-performance-state" property. Otherwise the consumers can define
their requirements with help of other infrastructure, for example the
OPP table (added in a later commit).

Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
Tested-by: Rajendra Nayak <rnayak@...eaurora.org>
---
 .../devicetree/bindings/power/power_domain.txt     | 67 ++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 723e1ad937da..9be09e576f68 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -38,6 +38,33 @@ phandle arguments (so called PM domain specifiers) of length specified by the
   domain's idle states. In the absence of this property, the domain would be
   considered as capable of being powered-on or powered-off.
 
+- performance-states : This describes the performance states of a PM domain.
+  The performance-states node reflects the performance states of this PM domain
+  and not the performance states of the devices or sub-domains in the PM domain.
+  Sub domains can have their own performance states. Sub domains without their
+  own performance states are governed by the performance states of the parent
+  domain and the "domain-performance-state" properties of their consumers refer
+  to the "reg" properties of the nodes in the parent domain.
+
+  Required properties of the performance-states node:
+  - compatible: Allow performance states to express their compatibility. It
+    should be: "domain-performance-state".
+
+  - nodes: The performance-states node should contain one or
+    more nodes, each representing a supported performance state.
+
+    Required properties of the performance state nodes:
+    - reg: A positive integer value representing the performance level
+      associated with a performance state. The integer value '0' represents the
+      lowest performance level and the highest value represents the highest
+      performance level. The exact meaning and performance implications of
+      individual values is left to be defined by the user platform.
+
+    Optional properties of performance state nodes:
+    - domain-microvolt: voltage in micro Volts. A single regulator's voltage is
+      specified with an array of size one or three.  Single entry is for target
+      voltage and three entries are for <target min max> voltages.
+
 Example:
 
 	power: power-controller@...40000 {
@@ -118,4 +145,44 @@ The node 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".
 
+Optional properties:
+- domain-performance-state: A positive integer value representing the minimum
+  performance level (of the parent domain) required by the consumer for its
+  working. The integer value '0' represents the lowest performance level and the
+  highest value represents the highest performance level. The value of
+  domain-performance-state field should match one of the "reg" fields in the
+  "performance-states" table of the parent power domain.
+
+
+Example:
+
+	parent: power-controller@...40000 {
+		compatible = "foo,power-controller";
+		reg = <0x12340000 0x1000>;
+		#power-domain-cells = <0>;
+
+		performance-states {
+			compatible = "domain-performance-state";
+			pstate@1 {
+				reg = <1>;
+				domain-microvolt = <970000 975000 985000>;
+			};
+			pstate@2 {
+				reg = <2>;
+				domain-microvolt = <1000000 1075000 1085000>;
+			};
+			pstate@3 {
+				reg = <3>;
+				domain-microvolt = <1100000 1175000 1185000>;
+			};
+		};
+	};
+
+	leaky-device@...50000 {
+		compatible = "foo,i-leak-current";
+		reg = <0x12350000 0x1000>;
+		power-domains = <&power 0>;
+		domain-performance-state = <2>;
+	};
+
 [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
-- 
2.7.1.410.g6faf27b

Powered by blists - more mailing lists