devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Rafael Wysocki <rjw@rjwysocki.net>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@codeaurora.org>
Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	robh@kernel.org, d-gerlach@ti.com, broonie@kernel.org,
	devicetree@vger.kernel.org,
	Viresh Kumar <viresh.kumar@linaro.org>
Subject: [PATCH V7 02/10] PM / OPP: Reword binding supporting multiple regulators per device
Date: Thu,  1 Dec 2016 16:28:15 +0530	[thread overview]
Message-ID: <838bd6b145f769c6531cec62b009bbec346e28d4.1480564564.git.viresh.kumar@linaro.org> (raw)
In-Reply-To: <cover.1480564564.git.viresh.kumar@linaro.org>
In-Reply-To: <cover.1480564564.git.viresh.kumar@linaro.org>

On certain platforms (like TI), DVFS for a single device (CPU) requires
configuring multiple power supplies.

The OPP bindings already contains binding and example to explain this
case, but it isn't sufficient.

- There is no way for the code parsing these bindings to know which
  voltage values belong to which power supply.

- It is not possible to know the order in which the supplies need to be
  configured while switching OPPs.

This patch clarifies on those details by mentioning that such
information is left for the implementation specific bindings to explain.
They may want to hardcode such details or implement their own properties
to get such information. All implementations using multiple regulators
for their devices must provide a binding document explaining their
implementation.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
---
 Documentation/devicetree/bindings/opp/opp.txt | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index f0239f68d186..9f5ca4457b5f 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -86,8 +86,14 @@ properties.
   Single entry is for target voltage and three entries are for <target min max>
   voltages.
 
-  Entries for multiple regulators must be present in the same order as
-  regulators are specified in device's DT node.
+  Entries for multiple regulators shall be provided in the same field separated
+  by angular brackets <>. The OPP binding doesn't provide any provisions to
+  relate the values to their power supplies or the order in which the supplies
+  need to be configured and that is left for the implementation specific
+  binding.
+
+  Entries for all regulators shall be of the same size, i.e. either all use a
+  single value or triplets.
 
 - opp-microvolt-<name>: Named opp-microvolt property. This is exactly similar to
   the above opp-microvolt property, but allows multiple voltage ranges to be
@@ -104,10 +110,13 @@ properties.
 
   Should only be set if opp-microvolt is set for the OPP.
 
-  Entries for multiple regulators must be present in the same order as
-  regulators are specified in device's DT node. If this property isn't required
-  for few regulators, then this should be marked as zero for them. If it isn't
-  required for any regulator, then this property need not be present.
+  Entries for multiple regulators shall be provided in the same field separated
+  by angular brackets <>. If current values aren't required for a regulator,
+  then it shall be filled with 0. If current values aren't required for any of
+  the regulators, then this field is not required. The OPP binding doesn't
+  provide any provisions to relate the values to their power supplies or the
+  order in which the supplies need to be configured and that is left for the
+  implementation specific binding.
 
 - opp-microamp-<name>: Named opp-microamp property. Similar to
   opp-microvolt-<name> property, but for microamp instead.
-- 
2.7.1.410.g6faf27b


  reply	other threads:[~2016-12-01 10:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01 10:58 [PATCH V7 00/10] PM / OPP: Multiple regulator support Viresh Kumar
2016-12-01 10:58 ` Viresh Kumar [this message]
     [not found] ` <cover.1480564564.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-12-01 10:58   ` [PATCH V7 01/10] PM / OPP: Fix incorrect cpu-supply property in binding Viresh Kumar
2016-12-01 10:58   ` [PATCH V7 03/10] PM / OPP: Don't use OPP structure outside of rcu protected section Viresh Kumar
2016-12-01 10:58   ` [PATCH V7 04/10] PM / OPP: Manage supply's voltage/current in a separate structure Viresh Kumar
2016-12-01 10:58   ` [PATCH V7 05/10] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage() Viresh Kumar
2016-12-01 10:58   ` [PATCH V7 07/10] PM / OPP: Separate out _generic_set_opp() Viresh Kumar
2016-12-01 10:58   ` [PATCH V7 10/10] PM / OPP: Don't assume platform doesn't have regulators Viresh Kumar
2016-12-01 10:58 ` [PATCH V7 06/10] PM / OPP: Add infrastructure to manage multiple regulators Viresh Kumar
2016-12-07  0:39   ` Stephen Boyd
2016-12-01 10:58 ` [PATCH V7 08/10] PM / OPP: Allow platform specific custom set_opp() callbacks Viresh Kumar
2016-12-01 10:58 ` [PATCH V7 09/10] PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators() Viresh Kumar
2016-12-05 14:21 ` [PATCH V7 00/10] PM / OPP: Multiple regulator support Viresh Kumar
     [not found]   ` <CAKohpokXXhcrhzqs+iW+1kTYjyF47bHF0TupMxP=4cSqXOThtA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-12-06  1:34     ` Rafael J. Wysocki
     [not found]       ` <CAJZ5v0gykH+UwMvgU3SCVgxg9Ufe23zQ1o9bEvnjtafVqjLa8Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-12-06  3:15         ` Viresh Kumar
2016-12-07  0:37           ` Stephen Boyd

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=838bd6b145f769c6531cec62b009bbec346e28d4.1480564564.git.viresh.kumar@linaro.org \
    --to=viresh.kumar@linaro.org \
    --cc=broonie@kernel.org \
    --cc=d-gerlach@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vireshk@kernel.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).