Thread (14 messages) 14 messages, 5 authors, 2016-11-16

Re: [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device

From: Rob Herring <hidden>
Date: 2016-11-15 02:00:07
Also in: linux-pm, lkml

On Fri, Nov 11, 2016 at 08:41:20AM +0530, Viresh Kumar wrote:
quoted hunk ↗ jump to hunk
On 10-11-16, 14:51, Stephen Boyd wrote:
quoted
On 11/10, Viresh Kumar wrote:
quoted
On 10-11-16, 16:36, Mark Brown wrote:
quoted
On Thu, Nov 10, 2016 at 09:34:40AM +0530, Viresh Kumar wrote:
quoted
On 09-11-16, 14:58, Mark Brown wrote:
quoted
On Wed, Oct 26, 2016 at 12:02:56PM +0530, Viresh Kumar wrote:
quoted
quoted
quoted
+  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.
quoted
quoted
I don't understand how this works.  If we have an unordered list of
values to set for regulators how will we make sense of them?
quoted
The platform driver is responsible to identify the order and pass it on to the
OPP core. And the platform driver needs to have that hard coded.
That *really* should be in the binding.
Okay, how do you suggest doing that? Will a property like supply-names
in the OPP table be fine? Like this:
@@ -369,13 +378,16 @@ Example 4: Handling multiple regulators
                        compatible = "arm,cortex-a7";
                        ...
 
-                       cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
+                       vcc0-supply = <&cpu_supply0>;
+                       vcc1-supply = <&cpu_supply1>;
+                       vcc2-supply = <&cpu_supply2>;
                        operating-points-v2 = <&cpu0_opp_table>;
                };
        };
 
        cpu0_opp_table: opp_table0 {
                compatible = "operating-points-v2";
+               supply-names = "vcc0", "vcc1", "vcc2";
                opp-shared;
No. The supply names (and also clock names/index) should be left
up to the consumer of the OPP table. We don't want to encode any
sort of details like this between the OPP table and the consumer
of it in DT because then it seriously couples the OPP table to
the consumer device. "The binding" in this case that needs to be
updated is the consumer binding, to indicate that it correlated
foo-supply and bar-supply to index 0 and 1 of the OPP table
voltages.
Are you saying that we shall have a property like this then?
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index ee91cbdd95ee..733946df2fb8 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -389,7 +389,10 @@ Example 4: Handling multiple regulators
                        compatible = "arm,cortex-a7";
                        ...
 
-                       cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
+                       vcc0-supply = <&cpu_supply0>;
+                       vcc1-supply = <&cpu_supply1>;
+                       vcc2-supply = <&cpu_supply2>;
+                       opp-supply-names = "vcc0", "vcc1", "vcc2";
Uh, no. You already have the names in the *-supply properties. Yes, they 
are a PIA to retrieve compared to a *-names property, but that is the 
nature of this style of binding.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help