OPP: Introduce OPP (V2) bindings

Current OPP (Operating performance point) device tree bindings have been insufficient due to the inflexible nature of the original bindings. Over time, we have realized that Operating Performance Point definitions and usage is varied depending on the SoC and a "single size (just frequency, voltage) fits all" model which the original bindings attempted and failed.

The proposed next generation of the bindings addresses by providing a expandable binding for OPPs and introduces the following common shortcomings seen with the original bindings:

- Getting clock/voltage/current rails sharing information between CPUs. Shared by all cores vs independent clock per core vs shared clock per cluster.

- Support for specifying current levels along with voltages.

- Support for multiple regulators.

- Support for turbo modes.

- Other per OPP settings: transition latencies, disabled status, etc.?

- Expandability of OPPs in future.

This patch introduces new bindings "operating-points-v2" to get these problems solved. Refer to the bindings for more details.

We now have multiple versions of OPP binding and only one of them should be used per device.

Reviewed-by Rob Herring <[email protected]>

Signed-off-by Viresh Kumar <[email protected]>

Ok. I'm still interested to see if this binding will have to change to support how multiple regulators will be matched up with the device using the OPP.

But for now,

Reviewed-by Stephen Boyd <[email protected]>

Current OPP (Operating performance point) device tree bindings have been insufficient due to the inflexible nature of the original bindings. Over time, we have realized that Operating Performance Point definitions and usage is varied depending on the SoC and a "single size (just frequency, voltage) fits all" model which the original bindings attempted and failed.

The proposed next generation of the bindings addresses by providing a expandable binding for OPPs and introduces the following common shortcomings seen with the original bindings:

- Getting clock/voltage/current rails sharing information between CPUs. Shared by all cores vs independent clock per core vs shared clock per cluster.

- Support for specifying current levels along with voltages.

- Support for multiple regulators.

- Support for turbo modes.

- Other per OPP settings: transition latencies, disabled status, etc.?

- Expandability of OPPs in future.

This patch introduces new bindings "operating-points-v2" to get these problems solved. Refer to the bindings for more details.

We now have multiple versions of OPP binding and only one of them should be used per device.

Reviewed-by Rob Herring <[email protected]>

Signed-off-by Viresh Kumar <[email protected]>

On some platforms (Like Qualcomm's SoCs), it is not decided until runtime on what OPPs to use. The OPP tables can be fixed at compile time, but which table to use is found out only after reading some efuses (sort of an prom) and knowing characteristics of the SoC.

To support such platform we need to pass multiple OPP tables per device and hardware should be able to choose one and only one table out of those.

Update OPP-v2 bindings to support that.

Acked-by Nishanth Menon <[email protected]>

Reviewed-by Stephen Boyd <[email protected]>

Signed-off-by Viresh Kumar <[email protected]>

---
 Documentation/devicetree/bindings/power/opp.txt | 52 +++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

Documentation/devicetree/bindings/power/opp.txt +7 -0

index 259bf00edf7d..2938c52dbf84 100644
@@ -45,6 +45,9 @@ Devices supporting OPPs must set their "operating-points-v2" property with
 phandle to a OPP table in their DT node. The OPP core will use this phandle to
 find the operating points for the device.
 
+Devices may want to choose OPP tables at runtime and so can provide a list of
+phandles here. But only *one* of them should be chosen at runtime.
+
 If required, this can be extended for SoC vendor specfic bindings. Such bindings
 should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
 and should have a compatible description like: "operating-points-v2-<vendor>".

@@ -63,6 +66,9 @@ This describes the OPPs belonging to a device. This node can have following
   reference an OPP.
 
 Optional properties:
+- opp-name: Name of the OPP table, to uniquely identify it if more than one OPP
+  table is supplied in "operating-points-v2" property of device.
+
 - opp-shared: Indicates that device nodes using this OPP Table Node's phandle
   switch their DVFS state together, i.e. they share clock/voltage/current lines.
   Missing property means devices have independent clock/voltage/current lines,

@@ -396,3 +402,49 @@ Example 4: Handling multiple regulators
                };
        };
 };
+

Quoted 1 line

+ operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>;

You've made a fundamental change here in that this can now be a list of phandles. There should be some description on what a list means (merge the tables?, select one?).

Documentation/devicetree/bindings/power/opp.txt Devices supporting OPPs must set their "operating-points-v2" property with · line 49

Quoted 2 lines

Documentation/devicetree/bindings/power/opp.txt +2 -0

+Devices may want to choose OPP tables at runtime and so can provide a list of
+phandles here. But only *one* of them should be chosen at runtime.

I think this needs to have a defined order and the platform should know what that is. For example, if you read the efuses and decide you need the "slow" table, you know to pick the first entry. Then you don't need opp-name. Does that work for QCom?

Quoted 5 lines · Rob Herring

Quoted 1 line

+ operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>;

You've made a fundamental change here in that this can now be a list of phandles. There should be some description on what a list means (merge the tables?, select one?).

Did you miss the description I wrote few lines earlier or are you asking for something else? This is what I wrote earlier:

Quoted 2 lines

Documentation/devicetree/bindings/power/opp.txt Devices supporting OPPs must set their "operating-points-v2" property with · line 49

Quoted 2 lines

Documentation/devicetree/bindings/power/opp.txt +2 -0

+Devices may want to choose OPP tables at runtime and so can provide a list of
+phandles here. But only *one* of them should be chosen at runtime.

So, clearly only ONE of the tables should be used.

Quoted 5 lines

I think this needs to have a defined order and the platform should know what that is. For example, if you read the efuses and decide you need the "slow" table, you know to pick the first entry. Then you don't need opp-name. Does that work for QCom?

Why forcing on the order here? For example, consider a case where the platform can have four tables, A B C D. Now DT is free to pass all four or just a subset of those. Like, for some boards table B doesn't stand valid. And so it may wanna pass just A C D. And so keeping these tables in order is going to break for sure. Flexibility is probably better in this case.

Defined order is a key part of DT bindings. We solve the variable length problem with name lists associated with variable length property like:

operating-point-names = "slow", "fast";

I'm not a fan of doing this if we can avoid it, but we should at least follow the same pattern. Don't send me a patch with that yet, I want to hear from Stephen.

You can also use "status" to disable specific tables rather than removing from the list.

Quoted 11 lines · Viresh Kumar

Quoted 4 lines · Rob Herring

Quoted 1 line

+ operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>;

You've made a fundamental change here in that this can now be a list of phandles. There should be some description on what a list means (merge the tables?, select one?).

Did you miss the description I wrote few lines earlier or are you asking for something else? This is what I wrote earlier:

Quoted 2 lines

Documentation/devicetree/bindings/power/opp.txt Devices supporting OPPs must set their "operating-points-v2" property with · line 49

Quoted 2 lines

Documentation/devicetree/bindings/power/opp.txt +2 -0

+Devices may want to choose OPP tables at runtime and so can provide a list of
+phandles here. But only *one* of them should be chosen at runtime.

So, clearly only ONE of the tables should be used.

Yes, never mind.

Quoted 10 lines

Quoted 4 lines

I think this needs to have a defined order and the platform should know what that is. For example, if you read the efuses and decide you need the "slow" table, you know to pick the first entry. Then you don't need opp-name. Does that work for QCom?

Why forcing on the order here? For example, consider a case where the platform can have four tables, A B C D. Now DT is free to pass all four or just a subset of those. Like, for some boards table B doesn't stand valid. And so it may wanna pass just A C D. And so keeping these tables in order is going to break for sure. Flexibility is probably better in this case.

Defined order is a key part of DT bindings. We solve the variable length problem with name lists associated with variable length property like:

operating-point-names = "slow", "fast";

I'm not a fan of doing this if we can avoid it, but we should at least follow the same pattern. Don't send me a patch with that yet, I want to hear from Stephen.

You can also use "status" to disable specific tables rather than removing from the list.

An operating-point(s?)-names property seems ok... but doesn't that mean that every CPU that uses the OPP has to have the same list of operating-point-names?

It would make sense to me if the operating points
were called something different depending on *which* CPU is using them, but in this case the only name for the operating point is "slow" or "fast", etc.

In reality we've assigned them names like speedX-binY-vZ so that we know which speed bin, voltage bin, and version they're part of. Maybe OPP node properties like qcom,speed-bin = <u32>, qcom,pvs-bin = <u32>, etc. would be better?

At the least, operating-points-names will be required on qcom platforms. A fixed ordering known to the platform would mean that we know exactly how many voltage bins and speed bins and how many voltage bins per speed bin are used for a particular SoC, which we've avoided knowing so far.

Why do you think so? For me the operating-points-v2-names property will be present in CPU node (as there is no OPP node which can have it) and so every CPU is free to choose what it wants to.

Quoted 3 lines · Viresh Kumar

Why do you think so? For me the operating-points-v2-names property will be present in CPU node (as there is no OPP node which can have it) and so every CPU is free to choose what it wants to.

So, I had something like this in mind:

From: Viresh Kumar <[email protected]>
Date: Thu, 30 Apr 2015 17:38:00 +0530
Subject: [PATCH] OPP: Allow multiple OPP tables to be passed via DT

On some platforms (Like Qualcomm's SoCs), it is not decided until runtime on what OPPs to use. The OPP tables can be fixed at compile time, but which table to use is found out only after reading some efuses (sort of an prom) and knowing characteristics of the SoC.

To support such platform we need to pass multiple OPP tables per device and hardware should be able to choose one and only one table out of those.

Update operating-points-v2 bindings to support that.

Signed-off-by Viresh Kumar <[email protected]>

---
 Documentation/devicetree/bindings/power/opp.txt | 63 +++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

Documentation/devicetree/bindings/power/opp.txt +11 -0

index 259bf00edf7d..72ccacaac9c9 100644
@@ -45,10 +45,21 @@ Devices supporting OPPs must set their "operating-points-v2" property with
 phandle to a OPP table in their DT node. The OPP core will use this phandle to
 find the operating points for the device.
 
+Devices may want to choose OPP tables at runtime and so can provide a list of
+phandles here. But only *one* of them should be chosen at runtime. This must be
+accompanied by a corresponding "operating-points-v2-names" property, to uniquely
+identify the OPP tables.
+
 If required, this can be extended for SoC vendor specfic bindings. Such bindings
 should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
 and should have a compatible description like: "operating-points-v2-<vendor>".
 
+Optional properties:
+- operating-points-v2-names: Names of OPP tables (required if multiple OPP
+  tables are present), to uniquely identify them. The same list must be present
+  for all the CPUs which are sharing clock/voltage rails and hence the OPP
+  tables.
+
 * OPP Table Node
 
 This describes the OPPs belonging to a device. This node can have following

Quoted 16 lines · Viresh Kumar

Quoted 3 lines · Viresh Kumar

Why do you think so? For me the operating-points-v2-names property will be present in CPU node (as there is no OPP node which can have it) and so every CPU is free to choose what it wants to.

So, I had something like this in mind:

From: Viresh Kumar <[email protected]>
Date: Thu, 30 Apr 2015 17:38:00 +0530
Subject: [PATCH] OPP: Allow multiple OPP tables to be passed via DT

On some platforms (Like Qualcomm's SoCs), it is not decided until runtime on what OPPs to use. The OPP tables can be fixed at compile time, but which table to use is found out only after reading some efuses (sort of an prom) and knowing characteristics of the SoC.

Quoted 7 lines

To support such platform we need to pass multiple OPP tables per device and hardware should be able to choose one and only one table out of those.

Update operating-points-v2 bindings to support that.

Signed-off-by Viresh Kumar <[email protected]>

Looks mostly ok..

Quoted 21 lines

---
 Documentation/devicetree/bindings/power/opp.txt | 63 +++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

Documentation/devicetree/bindings/power/opp.txt +5 -0

index 259bf00edf7d..72ccacaac9c9 100644
@@ -45,10 +45,21 @@ Devices supporting OPPs must set their "operating-points-v2" property with
 phandle to a OPP table in their DT node. The OPP core will use this phandle to
 find the operating points for the device.
 
+Devices may want to choose OPP tables at runtime and so can provide a list of
+phandles here. But only *one* of them should be chosen at runtime. This must be
+accompanied by a corresponding "operating-points-v2-names" property, to uniquely
+identify the OPP tables.
+
 If required, this can be extended for SoC vendor specfic bindings. Such bindings
 should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
 and should have a compatible description like: "operating-points-v2-<vendor>".
 

Documentation/devicetree/bindings/power/opp.txt Devices supporting OPPs must set their "operating-points-v2" property with · line 58

Quoted 2 lines

Documentation/devicetree/bindings/power/opp.txt +2 -0

+Optional properties:
+- operating-points-v2-names: Names of OPP tables (required if multiple OPP

Quoted 10 lines

Documentation/devicetree/bindings/power/opp.txt +4 -0

+  tables are present), to uniquely identify them. The same list must be present
+  for all the CPUs which are sharing clock/voltage rails and hence the OPP
+  tables.
+
 * OPP Table Node
 
 This describes the OPPs belonging to a device. This node can have following

@@ -63,11 +74,16 @@ This describes the OPPs belonging to a device. This node can have following
   reference an OPP.
 

Documentation/devicetree/bindings/power/opp.txt This describes the OPPs belonging to a device. This node can have following · line 79

Quoted 4 lines

Documentation/devicetree/bindings/power/opp.txt +3 -0

 Optional properties:
+- opp-name: Name of the OPP table, to uniquely identify it if more than one OPP
+  table is supplied in "operating-points-v2" property of device.
+

But isn't this being removed? If it is removed, feel free to add

Reviewed-by Stephen Boyd <[email protected]>

Quoted 1 line · Stephen Boyd

But isn't this being removed? If it is removed, feel free to add

Quoted 1 line

Reviewed-by Stephen Boyd <[email protected]>

Acked-by Rob Herring <[email protected]>

Quoted 3 lines · Stephen Boyd

An operating-point(s?)-names property seems ok... but doesn't that mean that every CPU that uses the OPP has to have the same list of operating-point-names?

Why do you think so? For me the operating-points-v2-names property will be present in CPU node (as there is no OPP node which can have it) and so every CPU is free to choose what it wants to.

Quoted 5 lines

It would make sense to me if the operating points
were called something different depending on *which* CPU is using them, but in this case the only name for the operating point is "slow" or "fast", etc.

I am completely confused now. :)

The problem you stated now was there with the current state of bindings. The name is embedded into the OPP table node and so is fixed for all the CPUs. Moving it to the CPU node will give all CPUs a chance to name it whatever they want to. And the same list has to be replicated to all CPUs sharing the clock rails.

Quoted 4 lines

In reality we've assigned them names like speedX-binY-vZ so that we know which speed bin, voltage bin, and version they're part of. Maybe OPP node properties like qcom,speed-bin = <u32>, qcom,pvs-bin = <u32>, etc. would be better?

Lets see, only if we can't get the generic stuff for this.

Quoted 4 lines

At the least, operating-points-names will be required on qcom platforms. A fixed ordering known to the platform would mean that we know exactly how many voltage bins and speed bins and how many voltage bins per speed bin are used for a particular SoC, which we've avoided knowing so far.

What are we referring to fixed ordering? If we have both a list of phandles to OPP tables and a list of names, they can be rearranged in whatever fashion we want. Isn't it?

Quoted 6 lines · Viresh Kumar

The problem you stated now was there with the current state of bindings. The name is embedded into the OPP table node and so is fixed for all the CPUs. Moving it to the CPU node will give all CPUs a chance to name it whatever they want to. And the same list has to be replicated to all CPUs sharing the clock rails.

Yes I don't see how the name will be different for any CPU, hence my complaint/question about duplicate names in each CPU. I guess it isn't any worse than clock-names though so I'm fine with it.

Documentation/devicetree/bindings/power/opp.txt Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.

Quoted 4 lines · Viresh Kumar

Documentation/devicetree/bindings/power/opp.txt +2 -1

+		opp-suspend = <&suspend_opp>;
 
-		opp00 {
+		suspend-opp: opp00 {

Minor nit, s/suspend-opp/suspend_opp

and here is updated patch

From: Viresh Kumar <[email protected]>
Date: Wed, 20 May 2015 08:27:49 +0530
Subject: [PATCH V8] OPP: Add binding for 'opp-suspend'

On few platforms, for power efficiency, we want the device to be configured for a specific OPP while we put the device in suspend state.

Add an optional property in operating-points-v2 bindings for that.

Acked-by Nishanth Menon <[email protected]>

Suggested-by Nishanth Menon <[email protected]>

Signed-off-by Viresh Kumar <[email protected]>

---
 Documentation/devicetree/bindings/power/opp.txt | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

Documentation/devicetree/bindings/power/opp.txt +10 -4

index 2938c52dbf84..29f115d26f7d 100644
@@ -74,6 +74,8 @@ This describes the OPPs belonging to a device. This node can have following
   Missing property means devices have independent clock/voltage/current lines,
   but they share OPP tables.
 
+- opp-suspend: Phandle of the OPP to set while device is suspended.
+
 
 * OPP Node
 

@@ -145,9 +147,10 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
 
 	cpu0_opp_table: opp_table0 {
 		compatible = "operating-points-v2";
+		opp-suspend = <&suspend_opp>;
 		opp-shared;
 
-		opp00 {
+		suspend_opp: opp00 {
 			opp-hz = <1000000000>;
 			opp-microvolt = <970000 975000 985000>;
 			opp-microamp = <70000>;

@@ -219,13 +222,14 @@ independently.
 
 	cpu_opp_table: opp_table {
 		compatible = "operating-points-v2";
+		opp-suspend = <&suspend_opp>;
 
 		/*
 		 * Missing opp-shared property means CPUs switch DVFS states
 		 * independently.
 		 */
 
-		opp00 {
+		suspend_opp: opp00 {
 			opp-hz = <1000000000>;
 			opp-microvolt = <970000 975000 985000>;
 			opp-microamp = <70000>;

@@ -298,9 +302,10 @@ DVFS state together.
 
 	cluster0_opp: opp_table0 {
 		compatible = "operating-points-v2";
+		opp-suspend = <&suspend_opp0>;
 		opp-shared;
 
-		opp00 {
+		suspend_opp: opp00 {
 			opp-hz = <1000000000>;
 			opp-microvolt = <970000 975000 985000>;
 			opp-microamp = <70000>;

@@ -323,9 +328,10 @@ DVFS state together.
 
 	cluster1_opp: opp_table1 {
 		compatible = "operating-points-v2";
+		opp-suspend = <&suspend_opp1>;
 		opp-shared;
 
-		opp10 {
+		suspend_opp: opp10 {
 			opp-hz = <1300000000>;
 			opp-microvolt = <1045000 1050000 1055000>;
 			opp-microamp = <95000>;

On few platforms, for power efficiency, we want the device to be configured for a specific OPP while we put the device in suspend state.

Add an optional property in operating-points-v2 bindings for that.

Acked-by Nishanth Menon <[email protected]>

Suggested-by Nishanth Menon <[email protected]>

Signed-off-by Viresh Kumar <[email protected]>

---
 Documentation/devicetree/bindings/power/opp.txt | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

Documentation/devicetree/bindings/power/opp.txt +0 -0

index 2938c52dbf84..6c245d87dd50 100644

Documentation/devicetree/bindings/power/opp.txt +8 -5

 * OPP Node
 

@@ -145,9 +147,10 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
 
        cpu0_opp_table: opp_table0 {
                compatible = "operating-points-v2";
+               opp-suspend = <&suspend_opp>;
                opp-shared;
 
-               opp00 {
+               suspend-opp: opp00 {
                        opp-hz = <1000000000>;
                        opp-microvolt = <970000 975000 985000>;
                        opp-microamp = <70000>;

@@ -219,13 +222,14 @@ independently.
 
        cpu_opp_table: opp_table {
                compatible = "operating-points-v2";
+               opp-suspend = <&suspend_opp>;
 
                /*
                 * Missing opp-shared property means CPUs switch DVFS states
                 * independently.
                 */
 
-               opp00 {
+               suspend-opp: opp00 {
                        opp-hz = <1000000000>;
                        opp-microvolt = <970000 975000 985000>;
                        opp-microamp = <70000>;

@@ -298,9 +302,10 @@ DVFS state together.
 
        cluster0_opp: opp_table0 {
                compatible = "operating-points-v2";
+               opp-suspend = <&suspend_opp0>;
                opp-shared;
 
-               opp00 {
+               suspend-opp: opp00 {
                        opp-hz = <1000000000>;
                        opp-microvolt = <970000 975000 985000>;
                        opp-microamp = <70000>;

@@ -323,9 +328,10 @@ DVFS state together.
 
        cluster1_opp: opp_table1 {
                compatible = "operating-points-v2";
+               opp-suspend = <&suspend_opp1>;
                opp-shared;
 
-               opp10 {
+               suspend-opp: opp10 {
                        opp-hz = <1300000000>;
                        opp-microvolt = <1045000 1050000 1055000>;
                        opp-microamp = <95000>;
--

2.4.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 2 lines

+- opp-suspend: Phandle of the OPP to set while device is suspended. +

I would just do a bool property in the OPP you want.

Quoted 4 lines · Rob Herring

Quoted 2 lines

+- opp-suspend: Phandle of the OPP to set while device is suspended. +

I would just do a bool property in the OPP you want.

I will do that if you want, no big deal.

Quoted 7 lines · Viresh Kumar

Quoted 4 lines · Rob Herring

Quoted 2 lines

+- opp-suspend: Phandle of the OPP to set while device is suspended. +

I would just do a bool property in the OPP you want.

I will do that if you want, no big deal.

In order to not waste any time, here is the change you suggested. Ack the one (original change or this one) you like :)

------------------8<----------------------

From: Viresh Kumar <[email protected]>
Date: Wed, 20 May 2015 08:27:49 +0530
Subject: [PATCH V8] OPP: Add binding for 'opp-suspend'

On few platforms, for power efficiency, we want the device to be configured for a specific OPP while we put the device in suspend state.

Add an optional property in operating-points-v2 bindings for that.

Acked-by Nishanth Menon <[email protected]>

Suggested-by Nishanth Menon <[email protected]>

Signed-off-by Viresh Kumar <[email protected]>

---
V7->V8:
- opp-suspend is moved to OPPs instead of the table, and is bool now.

 Documentation/devicetree/bindings/power/opp.txt | 7 +++++++
 1 file changed, 7 insertions(+)

Documentation/devicetree/bindings/power/opp.txt +7 -1

index 2938c52dbf84..2d4291127003 100644
@@ -113,6 +113,9 @@ properties.
   frequency for a short duration of time limited by the device's power, current
   and thermal limits.
 
+- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
+  the table should have this.
+
 - status: Marks the node enabled/disabled.
 
 Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.

@@ -152,6 +155,7 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
                        opp-microvolt = <970000 975000 985000>;
                        opp-microamp = <70000>;
                        clock-latency-ns = <300000>;
+                       opp-suspend;
                };
                opp01 {
                        opp-hz = <1100000000>;

@@ -230,6 +234,7 @@ independently.
                        opp-microvolt = <970000 975000 985000>;
                        opp-microamp = <70000>;
                        clock-latency-ns = <300000>;
+                       opp-suspend;
                };
                opp01 {
                        opp-hz = <1100000000>;

@@ -305,6 +310,7 @@ DVFS state together.
                        opp-microvolt = <970000 975000 985000>;
                        opp-microamp = <70000>;
                        clock-latency-ns = <300000>;
+                       opp-suspend;
                };
                opp01 {
                        opp-hz = <1100000000>;

@@ -330,6 +336,7 @@ DVFS state together.
                        opp-microvolt = <1045000 1050000 1055000>;
                        opp-microamp = <95000>;
                        clock-latency-ns = <400000>;
+                       opp-suspend;
                };
                opp11 {
                        opp-hz = <1400000000>;
--

2.4.0

Quoted 23 lines · Viresh Kumar

Quoted 7 lines · Viresh Kumar

Quoted 4 lines · Rob Herring

Quoted 2 lines

+- opp-suspend: Phandle of the OPP to set while device is suspended. +

I would just do a bool property in the OPP you want.

I will do that if you want, no big deal.

In order to not waste any time, here is the change you suggested. Ack the one (original change or this one) you like :)

------------------8<----------------------

From: Viresh Kumar <[email protected]>
Date: Wed, 20 May 2015 08:27:49 +0530
Subject: [PATCH V8] OPP: Add binding for 'opp-suspend'

On few platforms, for power efficiency, we want the device to be configured for a specific OPP while we put the device in suspend state.

Add an optional property in operating-points-v2 bindings for that.

Quoted 6 lines

Acked-by Nishanth Menon <[email protected]>

Suggested-by Nishanth Menon <[email protected]>

Signed-off-by Viresh Kumar <[email protected]>

---
V7->V8:
- opp-suspend is moved to OPPs instead of the table, and is bool now.

Acked-by Rob Herring <[email protected]>

Does your ACK also apply to patches [1-2/3] in this series?

Quoted 1 line · Rafael J. Wysocki

Does your ACK also apply to patches [1-2/3] in this series?

His RBY tag is already present for 1/3 :)