linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
Date: Wed, 9 Sep 2015 11:57:22 +0530	[thread overview]
Message-ID: <20150909062722.GA5266@linux> (raw)
In-Reply-To: <CAL_JsqKMGp+3Z+oO6E0YYzjTCb=-R_QM=YF=B33NWayWmV057A@mail.gmail.com>

On 02-09-15, 13:58, Rob Herring wrote:
> What do you expect here? It is your job to close it. Ultimately, this
> will be your problem to deal with. If you have 10 different vendors
> doing selection of OPPs in 10 different ways you will not be able to
> change that easily later. Maybe if you can't come up with something
> common, then this should just not go into DT. You can always look at
> how to do this in a common way and move from the kernel to DT later.

After getting ranted a bit, here is an real attempt to solve the
problem in a generic way. I hope this can take care of the complexity
of both Qualcomm and ST Microelectronics SoCs.

@Lee and Stephen: Lemme know if this still wouldn't work :(

-------------------------8<-------------------------
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Wed, 9 Sep 2015 11:47:37 +0530
Subject: [PATCH] PM / OPP: Add "opp-cuts" and "opp-supply-version" bindings

For many platforms it is unknown until runtime, about which OPPs should
be used or if used what should be voltage range for the supplies for a
particular frequency. And this mostly depends on the version of the
device or hardware, for which the OPPs are getting used.

This patch adds two new OPP bindings to get this solved.

1. "opp-cuts": The purpose of this binding is to allow the platform to
   identify the valid OPPs based on the different levels of versions
   with which the hardware is identified.

2. "opp-supply-name": The purpose of this binding is to allow the
   platform to select the voltage range of the power supplies, for a
   valid OPP.

Both of these can be used together, as well as independently.

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

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index c56a6b1a44ef..def75f7a3614 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -98,6 +98,13 @@ This describes the OPPs belonging to a device. This node can have following
   information. But for multiple power-supplies, this must be set to pass
   triplet style values.
 
+- opp-supply-version: One or more strings describing version of the supplies on
+  the platform. This is useful for the cases, where the platform wants to select
+  the voltage range for supplies at runtime, based on the specific version of
+  the hardware. There should be one entry in opp-microvolt array, for each
+  string present here. OPPs for the device must be configured, only for a single
+  version of the supplies.
+
 - status: Marks the OPP table enabled/disabled.
 
 
@@ -144,6 +151,16 @@ properties.
 - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
   the table should have this.
 
+- opp-cuts: Variable length field that contains versions/cuts/substrate of the
+  hardware for which the OPP is supported. Should contain entry per level of
+  version type. For example: a platform with three levels of versions (cuts
+  substrate pcode), this field should be like <X Y Z>, where X corresponds to
+  different cuts, Y corresponds to different substrates and Z corresponds to
+  different pcodes the OPP supports. Each bit of the value corresponds to a
+  particular version of the level, and so we can have maximum 32 different
+  values of any level. A value of 0xFFFFFFFF means that all the versions of the
+  level are supported.
+
 - status: Marks the node enabled/disabled.
 
 Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
@@ -491,3 +508,76 @@ Example 5: Multiple OPP tables
 		};
 	};
 };
+
+Example 6: OPP selection based on hardware version
+(example: three levels of versions: cuts, substrate and pcode)
+
+/ {
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a7";
+			...
+
+			cpu-supply = <&cpu_supply>
+			operating-points-v2 = <&cpu0_opp_table_slow>;
+		};
+	};
+
+	opp_table {
+		compatible = "operating-points-v2";
+		status = "okay";
+		opp-shared;
+
+		opp00 {
+			/*
+			 * Supports all substrate and pcode versions for 0xf
+			 * cuts, i.e. only first four cuts.
+			 */
+			opp-cuts = <0xf 0xffffffff 0xffffffff>
+			opp-hz = /bits/ 64 <600000000>;
+			...
+		};
+
+		opp01 {
+			/*
+			 * Supports all substrate and pcode versions for 0x20
+			 * cuts, i.e. only the 6th cut.
+			 */
+			opp-cuts = <0x20 0xffffffff 0xffffffff>
+			opp-hz = /bits/ 64 <800000000>;
+			...
+		};
+	};
+};
+
+Example 7: Multiple voltage-ranges (opp-supply-version) per supply
+(example: device with 2 supplies: vcc0 and vcc1, with two possible ranges of
+voltages: slow and fast)
+
+/ {
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a7";
+			...
+
+			vcc0-supply = <&cpu_supply0>;
+			vcc1-supply = <&cpu_supply1>;
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+	};
+
+	cpu0_opp_table: opp_table0 {
+		compatible = "operating-points-v2";
+		supply-names = "vcc0", "vcc1";
+		opp-supply-version = "slow", "fast";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <1000000000>;
+			opp-microvolt = <900000 915000 925000>, /* Supply vcc0: slow */
+					<910000 925000 935000>, /* Supply vcc1: slow */
+					<970000 975000 985000>, /* Supply vcc0: fast */
+					<960000 965000 975000>; /* Supply vcc1: fast */
+		};
+	};
+};

  reply	other threads:[~2015-09-09  6:27 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27 15:20 [PATCH v4 1/2] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation Lee Jones
2015-07-27 15:20 ` [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones
2015-07-28  2:29   ` Viresh Kumar
2015-07-28  7:34     ` Lee Jones
2015-07-28  7:47       ` Viresh Kumar
2015-07-28  8:30         ` Lee Jones
2015-07-28 22:55     ` Stephen Boyd
2015-07-29  8:14       ` Lee Jones
2015-07-29 22:15         ` Stephen Boyd
2015-07-30  8:46           ` Lee Jones
2015-07-30 16:16             ` Rob Herring
2015-07-31 16:37               ` Stephen Boyd
2015-08-01 11:36                 ` Viresh Kumar
2015-08-03  3:46                 ` Viresh Kumar
2015-08-10 13:22                   ` Lee Jones
2015-08-11  8:00                     ` Viresh Kumar
2015-08-11  9:30                       ` Lee Jones
2015-08-11 10:09                         ` Viresh Kumar
2015-08-11 11:54                           ` Lee Jones
2015-08-11 12:01                             ` Viresh Kumar
2015-08-11 13:27                               ` Lee Jones
2015-08-11 14:28                                 ` Viresh Kumar
2015-08-11 15:17                                   ` Lee Jones
2015-08-12 11:08                                     ` Viresh Kumar
2015-08-26 12:06                                       ` Lee Jones
2015-09-02  8:06                                         ` Viresh Kumar
2015-09-02 18:58                                           ` Rob Herring
2015-09-09  6:27                                             ` Viresh Kumar [this message]
2015-09-09  7:59                                               ` Lee Jones
2015-09-09  8:30                                                 ` Viresh Kumar
2015-09-09 13:39                                                   ` Lee Jones
2015-09-09 16:02                                                     ` Viresh Kumar
2015-09-09 16:36                                                       ` Lee Jones
2015-09-09 23:50                                                         ` Rob Herring
2015-09-10  0:57                                                           ` Stephen Boyd
2015-09-10  1:04                                                             ` Viresh Kumar
2015-09-10  8:31                                                               ` Lee Jones
2015-09-16  4:33                                                                 ` Viresh Kumar
2015-09-16  6:52                                                                   ` Lee Jones
2015-07-28 13:55   ` Rob Herring
2015-07-28 14:39     ` Lee Jones
2015-07-28 15:35       ` Rob Herring
2015-07-28 15:43         ` Lee Jones
2015-07-28  2:23 ` [PATCH v4 1/2] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation Viresh Kumar
2015-07-28  7:41   ` Lee Jones
2015-07-28  7:50     ` Viresh Kumar
2015-07-28  8:35 ` Viresh Kumar
2015-07-28  8:55   ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150909062722.GA5266@linux \
    --to=viresh.kumar@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).