Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1525119 > unrolled thread

[PATCH 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

Started byViresh Kumar <viresh.kumar@linaro.org>
First post2016-11-18 10:30 +0100
Last post2016-11-18 10:30 +0100
Articles 2 — 1 participant

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/2] PM / Domains / OPP: Introduce domain-performance-state binding Viresh Kumar <viresh.kumar@linaro.org> - 2016-11-18 10:30 +0100
    [PATCH 2/2] PM / OPP: Introduce domain-performance-state binding to OPP nodes Viresh Kumar <viresh.kumar@linaro.org> - 2016-11-18 10:30 +0100

#1525119 — [PATCH 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

FromViresh Kumar <viresh.kumar@linaro.org>
Date2016-11-18 10:30 +0100
Subject[PATCH 0/2] PM / Domains / OPP: Introduce domain-performance-state binding
Message-ID<sENEB-5bP-3@gated-at.bofh.it>
Hello,

Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.

We had some discussions about it in the past on the PM list [1], which
is followed by discussions during the LPC. The outcome of all that was
that we should extend Power Domain framework to support active state
power management as well.

The power-domains until now were only concentrating on the idle state
management of the device and this needs to change in order to reuse the
infrastructure of power domains for active state management.

To get a complete picture of the proposed plan, following is what we
need to do:
- Create DT bindings to get domain performance state information for the
  platforms.
- Enhance OPP framework to parse these and call into the PM Qos
  framework with a performance state request.
- Enhance PM Qos framework to provide the API to be used by consumers
  (or OPP framework) and pass it on to the (Generic) Power Domain
  framework.
- Enhance Generic Power Domain framework to accept such requests,
  accumulate all belonging to a single power domain and call domain
  driver specific callback with the performance state we want for the
  domain.
- The domain driver shall then, in a platform specific way, set the
  requested performance level.
- Note that these features are applicable to the CPU, GPU and other IIO
  or non-IIO devices.
- There can be cases where a device can choose between multiple power
  domains based on what performance level we want for the device. In
  such cases, we should represent the multiplexer with a separate power
  domain. In effect, the device (or OPP table) will correspond to a
  single power domain, but the backend driver of that domain shall
  implement the multiplexing functionality.

This patchset implements the very first part of this chain and
introduces a new optional property for the consumers of the
power-domains: domain-performance-state. This property can be used
directly by the consumer or its OPP table.

--
viresh

[1] https://marc.info/?l=linux-pm&m=147747923708075&w=2

Viresh Kumar (2):
  PM / Domains: Introduce domain-performance-state binding
  PM / OPP: Introduce domain-performance-state binding to OPP nodes

 Documentation/devicetree/bindings/opp/opp.txt      | 57 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  6 +++
 2 files changed, 63 insertions(+)

-- 
2.7.1.410.g6faf27b

[toc] | [next] | [standalone]


#1525125 — [PATCH 2/2] PM / OPP: Introduce domain-performance-state binding to OPP nodes

FromViresh Kumar <viresh.kumar@linaro.org>
Date2016-11-18 10:30 +0100
Subject[PATCH 2/2] PM / OPP: Introduce domain-performance-state binding to OPP nodes
Message-ID<sENEC-5bP-19@gated-at.bofh.it>
In reply to#1525119
Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are represented by positive
integer values, a lower value represents lower performance state.

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 nodes directly.

But if the device needs the capability of switching to different domain
performance states, as they may need to support different clock rates,
then the per OPP node can be used to contain that information.

This patch introduces the domain-performance-state (already defined by
Power Domain bindings) to the per OPP node. It can contain a single
positive integer value. An example is also provided.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 Documentation/devicetree/bindings/opp/opp.txt | 57 +++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index ee91cbdd95ee..9fb7804f784d 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -145,6 +145,14 @@ properties.
 
 - status: Marks the node enabled/disabled.
 
+- domain-performance-state: A positive integer value representing the minimum
+  performance level (of the parent domain) required by the consumer for the
+  working of respective OPP. The integer value '1' represents the lowest
+  performance level and the highest value represents the highest performance
+  level. The consumer device node (which contains phandle to the OPP table in
+  its "operating-points-v2" property) should have its "power-domains" property
+  set as well.
+
 Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
 
 / {
@@ -517,3 +525,52 @@ Example 5: opp-supported-hw
 		};
 	};
 };
+
+Example 7: domain-Performance-state:
+(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
+
+/ {
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 0>;
+			clock-names = "cpu";
+			cpu-supply = <&cpu_supply0>;
+			operating-points-v2 = <&cpu0_opp_table>;
+			power-domains = <&foo_pd>;
+		};
+	};
+
+	cpu0_opp_table: opp_table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp@1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			opp-microvolt = <970000 975000 985000>;
+			opp-microamp = <70000>;
+			clock-latency-ns = <300000>;
+			opp-suspend;
+			domain-performance-state = <1>;
+		};
+		opp@1100000000 {
+			opp-hz = /bits/ 64 <1100000000>;
+			opp-microvolt = <980000 1000000 1010000>;
+			opp-microamp = <80000>;
+			clock-latency-ns = <310000>;
+			domain-performance-state = <2>;
+		};
+		opp@1200000000 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <1025000>;
+			clock-latency-ns = <290000>;
+			turbo-mode;
+			domain-performance-state = <2>;
+		};
+	};
+};
-- 
2.7.1.410.g6faf27b

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web