OPP: Introduce OPP (V2) bindings

Documentation/devicetree/bindings/power/opp.txt line 61

Quoted 6 lines · Viresh Kumar

+- opp-microamp: current in micro Amperes. It can contain entries for multiple

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

+  regulators.
+
+  A single regulator's current is specified with an array of size one or three.
+  Single entry is for target current and three entries are for <target min max>
+  currents.

What is this for - are you trying to define OPPs for current regulators? If you are that's worrying, I can't think of a sensible use case. If that's not what's happening then the binding needs to be more specific about what this is supposed to mean.

Quoted 8 lines · Mark Brown

Quoted 6 lines · Viresh Kumar

+- opp-microamp: current in micro Amperes. It can contain entries for multiple

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

+  regulators.
+
+  A single regulator's current is specified with an array of size one or three.
+  Single entry is for target current and three entries are for <target min max>
+  currents.

Quoted 4 lines

What is this for - are you trying to define OPPs for current regulators? If you are that's worrying, I can't think of a sensible use case. If that's not what's happening then the binding needs to be more specific about what this is supposed to mean.

Its another property of the same voltage regulator we are using in opp-microvolt.
I hope that makes sense ?

But, perhaps I need to write it with more clarity? Or this field doesn't make sense ?

No, it doesn't - you're not answering the question about what this is for.

To know if this makes sense I need to know what you beleive "setting the current" does. If you literally mean setting the current it makes no sense at all. If you mean something else that something else should probably be written into the binding.

Quoted 2 lines · Mark Brown

No, it doesn't - you're not answering the question about what this is for.

I don't know how this information will be used finally. Probably the platform driver will do the configuration based on the volt-cur pair.

This still doesn't say what the value is supposed to mean which means it's not possible for someone to write generic code which handles the binding - saying that people can reference the value doesn't tell them how to interpret it. A limit? A nominal constant draw value? A value to regulate to? Those are all different things expressed as a current.

Quoted 5 lines · Mark Brown

This still doesn't say what the value is supposed to mean which means it's not possible for someone to write generic code which handles the binding - saying that people can reference the value doesn't tell them how to interpret it. A limit? A nominal constant draw value? A value to regulate to? Those are all different things expressed as a current.

@Stephen: Can you please answer these queries please, so that we can get the bindings correctly ?

If you look at the cpufreq/clock/pmic code on our codeaurora.org tree you'll see that it's used to pass a value with uA units through the regulator_set_optimum_mode() API. The call to regulator_set_optimum_mode() is here[1], and the place where we parse the OPP table from DT is here[2]. My understanding is that

Quoted 5 lines · Stephen Boyd

If you look at the cpufreq/clock/pmic code on our codeaurora.org tree you'll see that it's used to pass a value with uA units through the regulator_set_optimum_mode() API. The call to regulator_set_optimum_mode() is here[1], and the place where we parse the OPP table from DT is here[2]. My understanding is that

I'm not looking for anyone to explain this to me in e-mail, what I'm looking for is for the binding document to be clear so someone can tell what the binding means by reading the documentation for the binding.

Quoted 3 lines · Mark Brown

I'm not looking for anyone to explain this to me in e-mail, what I'm looking for is for the binding document to be clear so someone can tell what the binding means by reading the documentation for the binding.

Ok. Perhaps the simplest thing to do then is to reuse wording from the regulator_set_load() API documentation? That's the only usage of this value I'm aware of. Something like:

The current load of the device when using this OPP. Used to set the most efficient regulator operating mode.

We don't need any sort of min/max for this property either, so a single value should be all that's required.

That makes sense to me. Perhaps "current drawn by the device" rather than "current load of the device" since current is sadly overloaded :/

Thanks Mark. I have reworded it as:

- opp-microamp: Current drawn by the device in micro Amperes. It is used to set the most efficient regulator operating mode.

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.

Please let me know if this looks fine now.

That should be fine, microamperes is usually one word.

Quoted 2 lines · Mark Brown

That makes sense to me. Perhaps "current drawn by the device" rather than "current load of the device" since current is sadly overloaded :/

Thanks Mark. I have reworded it as:

- opp-microamp: Current drawn by the device in micro Amperes. It is used to set the most efficient regulator operating mode.

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.

Please let me know if this looks fine now.

just one minor concern being in the SoC end of the world :). In most times, the current consumption for a specific OPP varies depending on the specific location in the process node the die is -> this is even true among a single lot of wafers as well. some SoC vendors use hot, nominal and cold terminology to indicate the characteristics of the specific sample.

it might help state which sample end of the spectrum we are talking about here. reason being: if I put in values based on my board measurement, the results may not be similar to what someone else's sample be. Depending on technology, speed binning strategy used by the vendor, temperature and few other characteristics, these numbers could be widely divergent.

Quoted 7 lines

just one minor concern being in the SoC end of the world :). In most times, the current consumption for a specific OPP varies depending on the specific location in the process node the die is -> this is even true among a single lot of wafers as well. some SoC vendors use hot, nominal and cold terminology to indicate the characteristics of the specific sample.

Quoted 6 lines

it might help state which sample end of the spectrum we are talking about here. reason being: if I put in values based on my board measurement, the results may not be similar to what someone else's sample be. Depending on technology, speed binning strategy used by the vendor, temperature and few other characteristics, these numbers could be widely divergent.

I don't have any clue about this.. :(

@Mark/stephen: Any inputs ?

Quoting Viresh Kumar (2015-05-11 22:20:33)

Quoted 15 lines · Nishanth Menon

Quoted 7 lines

just one minor concern being in the SoC end of the world :). In most times, the current consumption for a specific OPP varies depending on the specific location in the process node the die is -> this is even true among a single lot of wafers as well. some SoC vendors use hot, nominal and cold terminology to indicate the characteristics of the specific sample.

Quoted 6 lines

it might help state which sample end of the spectrum we are talking about here. reason being: if I put in values based on my board measurement, the results may not be similar to what someone else's sample be. Depending on technology, speed binning strategy used by the vendor, temperature and few other characteristics, these numbers could be widely divergent.

Quoted 3 lines

I don't have any clue about this.. :(

@Mark/stephen: Any inputs ?

I do not think the idea of the mA property is to perfectly model current consumption at a given opp. Instead it is a nominal value that may be useful, e.g. for configuring a regulator in Stephen's case.

The TWLxxxx series of PMICs from TI have configurable SMPS which could possibly benefit from this info as well. Most of the time those are left in an "automatic mode", but there are manual programming steps to achieve higher efficiencies and this property could potentially help you do that.

While TWLxx series was kind of nascent in it's ability of choosing PWM/PFM or auto mode depending on the current targets, newer PMICs have their own unique techniques -> but, that said, this is a description of power consumption for a given OPP for the "device", How would stephen's case work with a PMIC and 2 devices which have different leakage characteristics (based on which end of the process spectrum they come from), Lets take an example:
device X consumes 800mA for OPPx
device Y consumes 900mA for OPPy

It is a lot more impactful than using relative numbers for other purposes - for example energy aware scheduling as an example -> here the actuals might have better optimization, but hints of relative power numbers by itself is pretty powerful information to help scheduling. The usage, in this case, unlike the usage for a PMIC efficiency selection, is not based on absolutes and is meant more of a hint (closer to usage such as clock transition latency numbers).

Quoted 9 lines · Nishanth Menon

While TWLxx series was kind of nascent in it's ability of choosing PWM/PFM or auto mode depending on the current targets, newer PMICs have their own unique techniques -> but, that said, this is a description of power consumption for a given OPP for the "device", How would stephen's case work with a PMIC and 2 devices which have different leakage characteristics (based on which end of the process spectrum they come from), Lets take an example:
device X consumes 800mA for OPPx
device Y consumes 900mA for OPPy

The system integrator would need to be somewhat conservative when specifying the currents involved. For plausible applications these are likely to be ballpark figures rather than anything too accurate - if nothing else the instantaneous current draw normally varies very substantially so realistically you're talking about a maximum here. If the corners vary that dramatically then I'd expect you'd see different OPP tables being used anyway.

Quoted 7 lines

It is a lot more impactful than using relative numbers for other purposes - for example energy aware scheduling as an example -> here the actuals might have better optimization, but hints of relative power numbers by itself is pretty powerful information to help scheduling. The usage, in this case, unlike the usage for a PMIC efficiency selection, is not based on absolutes and is meant more of a hint (closer to usage such as clock transition latency numbers).

You're not comparing two similar types of object here, you're trying to provide information on an actual physical value to get fed into other actual physical values.

Quoted 8 lines · Mark Brown

On Tue, May 12, 2015 at 02:14:19PM -0500, Nishanth Menon wrote:

specifying the currents involved. For plausible applications these are likely to be ballpark figures rather than anything too accurate - if nothing else the instantaneous current draw normally varies very substantially so realistically you're talking about a maximum here. If the corners vary that dramatically then I'd expect you'd see different OPP tables being used anyway.

OK - If we state "worst case", then it is quantifiable (if SoC vendors would like to expose such information - I doubt mine ever will ;) ).
- We might be able to quantify it better by stating worst case(under maximum load) steady state current (to avoid including transient spikes which are never representative) at ambient temperature(25C).

Quoted 10 lines · Nishanth Menon

Quoted 8 lines · Mark Brown

On Tue, May 12, 2015 at 02:14:19PM -0500, Nishanth Menon wrote:

specifying the currents involved. For plausible applications these are likely to be ballpark figures rather than anything too accurate - if nothing else the instantaneous current draw normally varies very substantially so realistically you're talking about a maximum here. If the corners vary that dramatically then I'd expect you'd see different OPP tables being used anyway.

Quoted 5 lines

OK - If we state "worst case", then it is quantifiable (if SoC vendors would like to expose such information - I doubt mine ever will ;) ).
- We might be able to quantify it better by stating worst case(under maximum load) steady state current (to avoid including transient spikes which are never representative) at ambient temperature(25C).

Qualcomm do. It kind of depends on the system how worst case it needs to be - it'll depend on the expected performance of both the system and potentially the regulator. For some systems it may be important to have some accounting for transients. Equally systems would only need to be as accurate as the underlying hardware was able to make use of.

- opp-microamp: The maximum current drawn by the device in microamperes considering system specific parameters (such as transients, process,
aging, etc.)
as necessary, at an ambient temperature of 25C. This may be used to set the most efficient regulator operating mode.

Quoted 5 lines · Nishanth Menon

- opp-microamp: The maximum current drawn by the device in microamperes considering system specific parameters (such as transients, process,
aging, etc.)
as necessary, at an ambient temperature of 25C. This may be used to set the most efficient regulator operating mode.

Why specify the temperature? That 25C is going to be terribly inefficient for my snowplow engine control system (or whatever).

If you look at the cpufreq/clock/pmic code on our codeaurora.org tree you'll see that it's used to pass a value with uA units through the regulator_set_optimum_mode() API. The call to regulator_set_optimum_mode() is here[1], and the place where we parse the OPP table from DT is here[2]. My understanding is that with recent changes to the regulator framework, we would do a s/regulator_set_optimum_mode/regulator_set_load/ and things would otherwise be the same on the consumer side. On the regulator side, we would move the .get_optimum_mode op to .set_load instead of the hack where we write to the hardware in .get_optimum_mode[3].

So does that mean it corresponds to a limit, or a nominal constant draw value, or a value to regulator to? From what I can tell it's used to figure out how many phases to enable[4]. I suspect that means it's being used to figure out what value it should regulate to. In newer PMICs this is all done automatically, but at least for some of the PMICs we need to do it manually.

Quoted 12 lines · Stephen Boyd

If you look at the cpufreq/clock/pmic code on our codeaurora.org tree you'll see that it's used to pass a value with uA units through the regulator_set_optimum_mode() API. The call to regulator_set_optimum_mode() is here[1], and the place where we parse the OPP table from DT is here[2]. My understanding is that with recent changes to the regulator framework, we would do a s/regulator_set_optimum_mode/regulator_set_load/ and things would otherwise be the same on the consumer side. On the regulator side, we would move the .get_optimum_mode op to .set_load instead of the hack where we write to the hardware in .get_optimum_mode[3].

Quoted 7 lines

So does that mean it corresponds to a limit, or a nominal constant draw value, or a value to regulator to? From what I can tell it's used to figure out how many phases to enable[4]. I suspect that means it's being used to figure out what value it should regulate to. In newer PMICs this is all done automatically, but at least for some of the PMICs we need to do it manually.

By current phases, you probably meant [1], right ?

Also what I couldn't understand is how are you controlling the current here?

- Is this a current only regulator ? Probably not as your code has a uv value as well..

- Now if uV is fixed, how is the target current controlled separately ?

- Should we have a min/max/target value of this current ? Like what we are doing for voltage. Or is this just the 'target' current ?

- And finally how exactly should we write this in bindings to make it clear to all users ?

Quoted 1 line · Viresh Kumar

- Now if uV is fixed, how is the target current controlled separately ?

uV is not fixed

Current OPP (Operating performance point) DT bindings are proven to be insufficient at multiple instances.

The shortcomings we are trying to solve here:

- Getting clock sharing information between CPUs. Single shared clock 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.

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

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

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

index 74499e5033fc..3b67a5c8d965 100644

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

+* Property: operating-points-v2
+
+Devices supporting OPPs must set their "operating-points-v2" property with
+phandle to a OPP descriptor in their DT node. The OPP core will use this phandle
+to find the operating points for the device.
+
+

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

+
+
+* OPP Node
+
+This defines voltage-current-frequency triplets along with other related
+properties.
+
+Required properties:
+- opp-khz: Frequency in kHz
+
+Optional properties:
+- opp-microvolt: voltage in micro Volts. It can contain entries for multiple
+  regulators.
+
+  A single regulator's voltage is specified with an array of size one or three.
+  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.
+
+- opp-microamp: current in micro Amperes. It can contain entries for multiple
+  regulators.
+
+  A single regulator's current is specified with an array of size one or three.
+  Single entry is for target current and three entries are for <target min max>
+  currents.
+

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

+
+Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
+
+/ {
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 0>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply0>;
+			operating-points-v2 = <&cpu0_opp>;
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a9";
+			reg = <1>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 0>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply0>;
+			operating-points-v2 = <&cpu0_opp>;
+		};
+	};
+
+	cpu0_opp: opp0 {
+		compatible = "operating-points-v2";
+		shared-opp;
+
+		entry00 {
+			opp-khz = <1000000>;
+			opp-microvolt = <970000 975000 985000>;
+			opp-microamp = <70000 75000 85000>;
+			clock-latency-ns = <300000>;
+		};
+		entry01 {
+			opp-khz = <1100000>;
+			opp-microvolt = <980000 1000000 1010000>;
+			opp-microamp = <80000 81000 82000>;
+			clock-latency-ns = <310000>;
+		};
+		entry02 {
+			opp-khz = <1200000>;
+			opp-microvolt = <1025000>;
+			clock-latency-ns = <290000>;
+			turbo-mode;
+		};
+	};
+};
+
+Example 2: Single cluster, Quad-core Qualcom-krait, switches DVFS states
+independently.
+
+/ {
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "qcom,krait";
+			reg = <0>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 0>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply0>;
+			operating-points-v2 = <&cpu0_opp>;
+		};
+
+		cpu at 1 {
+			compatible = "qcom,krait";
+			reg = <1>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 1>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply1>;
+			operating-points-v2 = <&cpu0_opp>;
+		};
+
+		cpu at 2 {
+			compatible = "qcom,krait";
+			reg = <2>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 2>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply2>;
+			operating-points-v2 = <&cpu0_opp>;
+		};
+
+		cpu at 3 {
+			compatible = "qcom,krait";
+			reg = <3>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 3>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply3>;
+			operating-points-v2 = <&cpu0_opp>;
+		};
+	};
+
+	cpu0_opp: opp0 {
+		compatible = "operating-points-v2";
+
+		/*
+		 * Missing shared-opp property means CPUs switch DVFS states
+		 * independently.
+		 */
+
+		entry00 {
+			opp-khz = <1000000>;
+			opp-microvolt = <970000 975000 985000>;
+			opp-microamp = <70000 75000 85000>;
+			clock-latency-ns = <300000>;
+		};
+		entry01 {
+			opp-khz = <1100000>;
+			opp-microvolt = <980000 1000000 1010000>;
+			opp-microamp = <80000 81000 82000>;
+			clock-latency-ns = <310000>;
+		};
+		entry02 {
+			opp-khz = <1200000>;
+			opp-microvolt = <1025000>;
+			opp-microamp = <90000;
+			lock-latency-ns = <290000>;
+			turbo-mode;
+		};
+	};
+};
+
+Example 3: Dual-cluster, Dual-core per cluster. CPUs within a cluster switch
+DVFS state together.
+
+/ {
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a7";
+			reg = <0>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 0>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply0>;
+			operating-points-v2 = <&cluster0_opp>;
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a7";
+			reg = <1>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 0>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply0>;
+			operating-points-v2 = <&cluster0_opp>;
+		};
+
+		cpu at 100 {
+			compatible = "arm,cortex-a15";
+			reg = <100>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 1>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply1>;
+			operating-points-v2 = <&cluster1_opp>;
+		};
+
+		cpu at 101 {
+			compatible = "arm,cortex-a15";
+			reg = <101>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 1>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply1>;
+			operating-points-v2 = <&cluster1_opp>;
+		};
+	};
+
+	cluster0_opp: opp0 {
+		compatible = "operating-points-v2";
+		shared-opp;
+
+		entry00 {
+			opp-khz = <1000000>;
+			opp-microvolt = <970000 975000 985000>;
+			opp-microamp = <70000 75000 85000>;
+			clock-latency-ns = <300000>;
+		};
+		entry01 {
+			opp-khz = <1100000>;
+			opp-microvolt = <980000 1000000 1010000>;
+			opp-microamp = <80000 81000 82000>;
+			clock-latency-ns = <310000>;
+		};
+		entry02 {
+			opp-khz = <1200000>;
+			opp-microvolt = <1025000>;
+			opp-microamp = <90000>;
+			clock-latency-ns = <290000>;
+			turbo-mode;
+		};
+	};
+
+	cluster1_opp: opp1 {
+		compatible = "operating-points-v2";
+		shared-opp;
+
+		entry10 {
+			opp-khz = <1300000>;
+			opp-microvolt = <1045000 1050000 1055000>;
+			opp-microamp = <95000 100000 105000>;
+			clock-latency-ns = <400000>;
+		};
+		entry11 {
+			opp-khz = <1400000>;
+			opp-microvolt = <1075000>;
+			opp-microamp = <100000>;
+			clock-latency-ns = <400000>;
+		};
+		entry12 {
+			opp-khz = <1500000>;
+			opp-microvolt = <1010000 1100000 1110000>;
+			opp-microamp = <95000 100000 105000>;
+			clock-latency-ns = <400000>;
+			turbo-mode;
+		};
+	};
+};
+
+Example 4: Handling multiple regulators
+
+/ {
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a7";
+			...
+
+			opp-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
+			operating-points-v2 = <&cpu0_opp>;
+		};
+	};
+
+	cpu0_opp: opp0 {
+		compatible = "operating-points-v2";
+		shared-opp;
+
+		entry00 {
+			opp-khz = <1000000>;
+			opp-microvolt = <970000>, /* Supply 0 */
+					<960000>, /* Supply 1 */
+					<960000>; /* Supply 2 */
+			opp-microamp =  <70000>,  /* Supply 0 */
+					<70000>,  /* Supply 1 */
+					<70000>;  /* Supply 2 */
+			clock-latency-ns = <300000>;
+		};
+
+		/* OR */
+
+		entry00 {
+			opp-khz = <1000000>;
+			opp-microvolt = <970000 975000 985000>, /* Supply 0 */
+					<960000 965000 975000>, /* Supply 1 */
+					<960000 965000 975000>; /* Supply 2 */
+			opp-microamp =  <70000  75000  85000>,  /* Supply 0 */
+					<70000  75000  85000>,  /* Supply 1 */
+					<70000  75000  85000>;  /* Supply 2 */
+			clock-latency-ns = <300000>;
+		};
+
+		/* OR */
+
+		entry00 {
+			opp-khz = <1000000>;
+			opp-microvolt = <970000 975000 985000>, /* Supply 0 */
+					<960000 965000 975000>, /* Supply 1 */
+					<960000 965000 975000>; /* Supply 2 */
+			opp-microamp =  <70000  75000  85000>,  /* Supply 0 */
+					<0	0      0>,	/* Supply 1 doesn't support current change */
+					<70000  75000  85000>;  /* Supply 2 */
+			clock-latency-ns = <300000>;
+		};
+	};
+};
+
+
+Deprecated Bindings
+-------------------
 

Properties:
- operating-points: An array of 2-tuples items, and each item consists

Quoted 1 line · Viresh Kumar

+the liberty of choosing these. These triplets are called Operating Performance

I suggest we dont call them as triplets either -> note, we have added clk transition latency per OPP, so they are not exactly triplets either.

Documentation/devicetree/bindings/power/opp.txt line 10

Quoted 5 lines

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

+Points aka OPPs. This document defines bindings for these OPPs applicable across
+wide range of devices. For illustration purpose, this document uses CPU as a
+device.
+
+

Would be good to point to operating-points (the legacy document) as well. It might be good to state that only one of the properties should be used for the device node OPP description.

Documentation/devicetree/bindings/power/opp.txt line 34

Quoted 5 lines

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

+Optional properties:
+- shared-opp: Indicates that device nodes using this OPP descriptor'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,
+  but they share OPP tables.

Is'nt this property redundant? by the fact that phandle is reused for cpu1 should indicate shared OPP table, correct?

Quoted 1 line

+- turbo-mode: Marks the OPP to be used only for turbo modes.

Might be great to add some description for what "turbo mode" means here.

That said, flexibility of this approach is awesome, thanks for doing this, I believe we did have a discussion about "safe OPP" for thermal behavior -> now that we have phandles for OPPs, we can give phandle pointer to the thermal framework. in addition, we can also use phandle for marking throttling information in thermal framework instead of indices as well. which allows a lot of flexibility.

in some systems, we'd have need to mark certain OPPs for entry into suspend(tegra?) or during shutdown (for example) - do we allow for such description as phandle pointer back to the OPP nodes (from cpu0 device) OR do we describe them as additional properties?

Quoted 1 line

+- status: Marks the node enabled/disabled.

One question we'd probably want the new framework to address is the need for OPPs based on Efuse options - Am I correct in believing that the solution that iMX, and TI SoCs probably need is something similar to modifying the status to disabled? or do we have Vendor specfic modifier properties that would be allowed?

One additional behavior need I noticed in various old threads is a need to restrict transition OPPs -> certain SoCs might have constraints on next OPP they can transition from certain OPPs in-order to achieve a new OPP. again, such behavior could be phandle lists OR properties that link the chain up together. Number of such needs did sound less, but still just thought to bring it up.

Quoted 1 line · Viresh Kumar

Quoted 11 lines

That said, flexibility of this approach is awesome, thanks for doing this, I believe we did have a discussion about "safe OPP" for thermal behavior -> now that we have phandles for OPPs, we can give phandle pointer to the thermal framework. in addition, we can also use phandle for marking throttling information in thermal framework instead of indices as well. which allows a lot of flexibility.

in some systems, we'd have need to mark certain OPPs for entry into suspend(tegra?) or during shutdown (for example) - do we allow for such description as phandle pointer back to the OPP nodes (from cpu0 device) OR do we describe them as additional properties?

Haven't thought about it earlier. In case we need them, probably it should go in the OPP table.

NOTE: Mike T. once told me that we shouldn't over-abuse the bindings by putting every detail there. And I am not sure at all on how to draw that line.

Quoted 8 lines

Quoted 2 lines

+- status: Marks the node enabled/disabled.

One question we'd probably want the new framework to address is the need for OPPs based on Efuse options - Am I correct in believing that the solution that iMX, and TI SoCs probably need is something similar to modifying the status to disabled? or do we have Vendor specfic modifier properties that would be allowed?

See PATCH 2/3 for that.

Quoted 7 lines

One additional behavior need I noticed in various old threads is a need to restrict transition OPPs -> certain SoCs might have constraints on next OPP they can transition from certain OPPs in-order to achieve a new OPP. again, such behavior could be phandle lists OR properties that link the chain up together. Number of such needs did sound less, but still just thought to bring it up.

See 0/3 and 3/3 for that. Its present in my solution but Mike T. is strictly against keeping that in OPP table. And so 3/3 may get Nak'd.

Just curious -> is'nt it better to just have min<->max range? binding as it stands right now is open to interpretation as to what will be attempted and in what sequence? with a valid min, target or max - is'nt it more power efficient always to go for a "min" than a target?

Further, min<->max implies anywhere in that range and is more consistent with "regulator like" description.

True. one option might be to allow for vendor specific property extensions - that will let vendors add in additional quirky data custom to their SoCs as needed.

Quoted 5 lines · Nishanth Menon

Just curious -> is'nt it better to just have min<->max range? binding as it stands right now is open to interpretation as to what will be attempted and in what sequence? with a valid min, target or max - is'nt it more power efficient always to go for a "min" than a target?

Quoted 2 lines

Further, min<->max implies anywhere in that range and is more consistent with "regulator like" description.

It came out after some discussions on the list, you may want to go through that.

https://lists.linaro.org/pipermail/linaro-kernel/2015-January/019844.html

What I dont see in the thread, and the point I raised here, why have nominal/typical voltage at all? min<->max should be sufficient, correct? If the device cannot function at min, then it should not be documented as part of valid range at all.

Quoted 4 lines · Nishanth Menon

What I dont see in the thread, and the point I raised here, why have nominal/typical voltage at all? min<->max should be sufficient, correct? If the device cannot function at min, then it should not be documented as part of valid range at all.

Going for the minimum specified voltage is asking for trouble with regard to tolerances and so on, see also your concern about process corners. If the electrical engineers specify things as X +/- Y the most conservative thing to do is to try to hit X rather than going straight for the limits.

To illustrate: What does it mean for a driver using regulator API? Attempt X <-> (X+Y), if that fails (example PMIC SMPS max < X), try (X-Y)<->(X)? If yes, then we do expect (X-Y)<->(X+Y) should be stable for all operating conditions for the device, correct? If this is is not stable at (X-Y), then we have a wrong specification for the device for claiming X +/- Y is a valid range for the device.

Quoted 6 lines · Nishanth Menon

To illustrate: What does it mean for a driver using regulator API? Attempt X <-> (X+Y), if that fails (example PMIC SMPS max < X), try (X-Y)<->(X)? If yes, then we do expect (X-Y)<->(X+Y) should be stable for all operating conditions for the device, correct? If this is is not stable at (X-Y), then we have a wrong specification for the device for claiming X +/- Y is a valid range for the device.

We have an explicit regulator API call for setting by tolerance which tries to get as close as possible to the target voltage (currently the implementation is very cheap and nasty but ideally it'll get improved).

Current OPP (Operating performance point) DT bindings are proven to be insufficient at multiple instances.

The shortcomings we are trying to solve here:

- Getting clock sharing information between CPUs. Single shared clock 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

operating-points-v2 is kinda awkward, how about operating-points-extended, much like interrupts-extended ?

Other than this, I very much like the new approach.

Current OPP (Operating performance point) DT bindings are proven to be insufficient at multiple instances.

The shortcomings we are trying to solve here:

- Getting clock sharing information between CPUs. Single shared clock 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.

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

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

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

index 74499e5033fc..3b67a5c8d965 100644
@@ -1,8 +1,366 @@
-* Generic OPP Interface
+Generic OPP (Operating Performance Points) Bindings
+----------------------------------------------------
 
-SoCs have a standard set of tuples consisting of frequency and
-voltage pairs that the device will support per voltage domain. These
-are called Operating Performance Points or OPPs.
+Devices work at voltage-current-frequency triplets and some implementations have
+the liberty of choosing these. These triplets are called Operating Performance
+Points aka OPPs. This document defines bindings for these OPPs applicable across
+wide range of devices. For illustration purpose, this document uses CPU as a
+device.
+
+
+* Property: operating-points-v2
+
+Devices supporting OPPs must set their "operating-points-v2" property with
+phandle to a OPP descriptor in their DT node. The OPP core will use this phandle
+to find the operating points for the device.
+
+
+* OPP Descriptor Node
+
+This describes the OPPs belonging to a device. This node can have following
+properties:
+
+Required properties:
+- compatible: Allow OPPs to express their compatibility. It should be:

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

+
+
+* OPP Node
+
+This defines voltage-current-frequency triplets along with other related
+properties.
+
+Required properties:
+- opp-khz: Frequency in kHz
+
+Optional properties:
+- opp-microvolt: voltage in micro Volts. It can contain entries for multiple
+  regulators.
+
+  A single regulator's voltage is specified with an array of size one or three.
+  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.
+
+- opp-microamp: current in micro Amperes. It can contain entries for multiple
+  regulators.
+
+  A single regulator's current is specified with an array of size one or three.
+  Single entry is for target current and three entries are for <target min max>
+  currents.

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

+
+Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
+
+/ {
+       cpus {
+               #address-cells = <1>;
+               #size-cells = <0>;
+
+               cpu at 0 {
+                       compatible = "arm,cortex-a9";
+                       reg = <0>;
+                       next-level-cache = <&L2>;
+                       clocks = <&clk_controller 0>;
+                       clock-names = "cpu";
+                       opp-supply = <&cpu_supply0>;
+                       operating-points-v2 = <&cpu0_opp>;
+               };
+
+               cpu at 1 {
+                       compatible = "arm,cortex-a9";
+                       reg = <1>;
+                       next-level-cache = <&L2>;
+                       clocks = <&clk_controller 0>;
+                       clock-names = "cpu";
+                       opp-supply = <&cpu_supply0>;
+                       operating-points-v2 = <&cpu0_opp>;
+               };
+       };
+
+       cpu0_opp: opp0 {
+               compatible = "operating-points-v2";
+               shared-opp;
+
+               entry00 {
+                       opp-khz = <1000000>;
+                       opp-microvolt = <970000 975000 985000>;
+                       opp-microamp = <70000 75000 85000>;
+                       clock-latency-ns = <300000>;
+               };
+               entry01 {
+                       opp-khz = <1100000>;
+                       opp-microvolt = <980000 1000000 1010000>;
+                       opp-microamp = <80000 81000 82000>;

Signature · 1 line

2.3.0.rc0.44.ga94655d

Quoting Viresh Kumar (2015-04-30 05:07:59)

Sorry for chiming in so late in the process. Also, sorry for the long email. Lots of repetition below:

Why should this new binding exist?

Is Devicetree really the right place
to put all of this data? If DT is the right place for some users, some of the time ... is it always the right place for all users, all of the time?

Quoted 1 line

- Expandability of OPPs in future.

This point above gives me heartburn. It appears that this binding is not meant to be "sub-classed" by vendor-specific compatible strings. Please let me know if I'm wrong on that.

The problem with this approach is that every little problem that someone has with the binding will have to be solved by changing the generic opp binding. I do not see how this can scale given the complexity of data, programming sequences and other stuff associated with operating points and dvfs transitions.

I like the existing operating points binding. It is very simple. The data can be entirely encoded in DT and then used by the driver for simple dvfs use cases.

Maybe we should just stop there and keep it simple? If the data needed to express an operating point or dvfs transition is very complex, why use DT for that?

Documentation/devicetree/bindings/power/opp.txt line 34

Quoted 5 lines

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

+Optional properties:
+- shared-opp: Indicates that device nodes using this OPP descriptor'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,
+  but they share OPP tables.

What is the behavior of not setting 'shared-opp'? The same table is re-used by multiple consumers/devices?

I think a provider/consumer model works better here. E.g. if we have 4 cpus that scale independently then there would be 4 opp providers, each provider corresponding to the unique frequency and voltage domains per cpu. If multiple cpu nodes consume the same opp phandle then the sharing becomes implicit: those cpus are in the same frequency and power domains.

This is how it works for other resources, such as specifying a clock or regulator in DT. If two device nodes reference that same resource then it clear that they are using the same physical hardware. Having just a table of data in a node that does not clearly map onto hardware (or a software abstraction that provides access to that hardware) is not as nice IMO.

Quoted 4 lines

+- clock-latency-ns: Specifies the maximum possible transition latency (in
+  nanoseconds) for switching to this OPP from any other OPP.
+- turbo-mode: Marks the OPP to be used only for turbo modes.
+- status: Marks the node enabled/disabled.

s/clock/transition/

Scaling the regulator can take longer than the clock. Better to reflect that this value is capturing the total transition time.

It seems wrong to me that the clock and supply data is owned by the cpu node, and not the opp descriptor. Everything about the opp transition should belong to a provider node. Then the cpu simply needs to consume that via a phandle.

Quoted 5 lines

+Deprecated Bindings
+-------------------

Properties:
- operating-points: An array of 2-tuples items, and each item consists

I think we should keep these. They work for the simple case.

Quoted 3 lines · Michael Turquette

Quoting Viresh Kumar (2015-04-30 05:07:59)

Why should this new binding exist?

The answer to this particular query is perhaps simple, i.e. we have unsolved problems that we wanted to solve in a generic way.

But probably the bigger question is "Should we really put the OPPs (new or old bindings) in DT".

Quoted 7 lines · Michael Turquette

Quoted 3 lines

Quoting Viresh Kumar (2015-04-30 05:07:59)

Why should this new binding exist?

The answer to this particular query is perhaps simple, i.e. we have unsolved problems that we wanted to solve in a generic way.

Quoted 2 lines

But probably the bigger question is "Should we really put the OPPs (new or old bindings) in DT".

And also is trying to do this in a completely generic manner the right way of going about things - do we really understand the problem area well enough to create a completely generic solution for all cases, bearing in mind that once things go into a DT binding they become an ABI?

No, we don't understand the problem space well enough to form an ABI.

Putting this stuff in C without any philosophical constraints on whether or not we can change it later is the way to go.

Quoted 1 line · Michael Turquette

No, we don't understand the problem space well enough to form an ABI.

And why do you think so? We have been facing many problems since a long time which we are trying to solve here.

I agree that it might not be right to try too many things which may not be required later, but most of the things we have now in new bindings are actually required.

Quoted 2 lines

Putting this stuff in C without any philosophical constraints on whether or not we can change it later is the way to go.

I don't agree to that :)

Quoting Mark Brown (2015-05-13 04:03:57)

Quoted 9 lines · Viresh Kumar

Quoted 7 lines · Michael Turquette

Quoted 3 lines

Quoting Viresh Kumar (2015-04-30 05:07:59)

Why should this new binding exist?

The answer to this particular query is perhaps simple, i.e. we have unsolved problems that we wanted to solve in a generic way.

Quoted 7 lines

Quoted 2 lines

But probably the bigger question is "Should we really put the OPPs (new or old bindings) in DT".

And also is trying to do this in a completely generic manner the right way of going about things - do we really understand the problem area well enough to create a completely generic solution for all cases, bearing in mind that once things go into a DT binding they become an ABI?

No, we don't understand the problem space well enough to form an ABI. And even if we did understand it perfectly today, the constraints and expressions will change tomorrow.

Putting this stuff in C without any philosophical constraints on whether or not we can change it later is the way to go.

Quoted 4 lines

It seems wrong to me that the clock and supply data is owned by the cpu node, and not the opp descriptor. Everything about the opp transition should belong to a provider node. Then the cpu simply needs to consume that via a phandle.

https://lists.linaro.org/pipermail/linaro-kernel/2014-December/019505.html

This argues that clock is an input to the cpu, this is not in-correct, but, it could also be argued that OPP tables are clock dependent.

For example, with multiple clock source options that a device might choose to select from internally(by some means.. lets not just restrict ourselves to just CPUs here for a moment), the tables might be different. We can always debate that this then is the responsibility of the driver handling the description for that device and we might want possibility of vice versa as well - same OPP table used by different clock source selections as well.

Quoted 2 lines · Nishanth Menon

This argues that clock is an input to the cpu, this is not in-correct, but, it could also be argued that OPP tables are clock dependent.

Quoted 7 lines

For example, with multiple clock source options that a device might choose to select from internally(by some means.. lets not just restrict ourselves to just CPUs here for a moment), the tables might be different. We can always debate that this then is the responsibility of the driver handling the description for that device and we might want possibility of vice versa as well - same OPP table used by different clock source selections as well.

@Rob: Any inputs ?

Quoted 3 lines · Viresh Kumar

Quoted 2 lines · Nishanth Menon

This argues that clock is an input to the cpu, this is not in-correct, but, it could also be argued that OPP tables are clock dependent.

What piece of h/w is the clock an input to then?

Quoted 10 lines

Quoted 8 lines

For example, with multiple clock source options that a device might choose to select from internally(by some means.. lets not just restrict ourselves to just CPUs here for a moment), the tables might be different. We can always debate that this then is the responsibility of the driver handling the description for that device and we might want possibility of vice versa as well - same OPP table used by different clock source selections as well.

@Rob: Any inputs ?

If you are going to describe this clock mux in DT, then that mux should be part of the h/w block that controls it. You could always add entries that describe what parent clock must be used for a given OPP, but that is a new binding and not part of the existing clock binding.

If things get too complicated, then don't try to describe this in DT. That is always an option.

Yes, ofcourse... it is always an option, we just tend to like to have all data in the same place if possible - DT is the preferred approach.

Current OPP (Operating performance point) DT bindings are proven to be insufficient at multiple instances.

The shortcomings we are trying to solve here:

- Getting clock sharing information between CPUs. Single shared clock 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.

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

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

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

index 74499e5033fc..3b67a5c8d965 100644
@@ -1,8 +1,366 @@
-* Generic OPP Interface
+Generic OPP (Operating Performance Points) Bindings
+----------------------------------------------------
 
-SoCs have a standard set of tuples consisting of frequency and
-voltage pairs that the device will support per voltage domain. These
-are called Operating Performance Points or OPPs.
+Devices work at voltage-current-frequency triplets and some implementations have
+the liberty of choosing these. These triplets are called Operating Performance
+Points aka OPPs. This document defines bindings for these OPPs applicable across
+wide range of devices. For illustration purpose, this document uses CPU as a
+device.
+
+
+* Property: operating-points-v2
+
+Devices supporting OPPs must set their "operating-points-v2" property with
+phandle to a OPP descriptor in their DT node. The OPP core will use this phandle
+to find the operating points for the device.
+
+
+* OPP Descriptor Node
+
+This describes the OPPs belonging to a device. This node can have following
+properties:
+
+Required properties:
+- compatible: Allow OPPs to express their compatibility. It should be:
+  "operating-points-v2".
+- OPP nodes: One or more OPP nodes describing voltage-current-frequency
+  triplets. Their name isn't significant but their phandle can be used to
+  reference an OPP.
+
+Optional properties:
+- shared-opp: Indicates that device nodes using this OPP descriptor'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,

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

+
+Optional properties:
+- opp-microvolt: voltage in micro Volts. It can contain entries for multiple
+  regulators.
+
+  A single regulator's voltage is specified with an array of size one or three.
+  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.
+

This looks like it covers my usecases. I'm not sure if I'm going to put all of this data in DT because of the philosophical question regarding what should be in DT and the technical decisions that some platforms I'm working on have made to encode parts of the OPPs in fuses, but at least the binding looks to support all the scenarios I have today.

Quoted 2 lines

+Required properties:
+- opp-khz: Frequency in kHz

Can this be in Hz? I thought there were some problems with kHz and Hz before where we wanted to make this into Hz so that rounding problems don't arise?

Also I wonder if all properties should be optional? I don't have this scenario today, but perhaps the frequencies could be encoded in fuses, but the voltages wouldn't be and so we might want to read out the frequencies for a fixed set of voltages. Of course, if there's nothing in the OPP node at all, it's not very useful, so perhaps some statement that at least one of the frequency/voltage/amperage properties should be present.

Documentation/devicetree/bindings/power/opp.txt line 65

Quoted 3 lines

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

+  Entries for multiple regulators must be present in the same order as
+  regulators are specified in device's DT node. If few regulators don't provide
+  capability to configure current, then values for then should be marked as

s/then/them/

Please put some space between properties so they can be found quickly:

Quoted 7 lines · Stephen Boyd

Also I wonder if all properties should be optional? I don't have this scenario today, but perhaps the frequencies could be encoded in fuses, but the voltages wouldn't be and so we might want to read out the frequencies for a fixed set of voltages. Of course, if there's nothing in the OPP node at all, it's not very useful, so perhaps some statement that at least one of the frequency/voltage/amperage properties should be present.

I am not sure. What we are trying to do (fill partially in DT and partially in platform), is a trick and not the right use of bindings.

Ideally whatever is passed in DT should be complete by itself and doesn't require platform to tweak it (which it can't). For example, the cpufreq-dt driver will try to initialize OPPs from the DT directly and wouldn't know about the platform tweaks. That can work eventually as platform will add OPPs for the same bindings before cpufreq driver will try to do, but that's a trick.

And then its all about frequency in the first place, and so marking that optional looks wrong. Probably not the right use of these bindings.

Quoted 19 lines · Viresh Kumar

Quoted 7 lines · Stephen Boyd

Also I wonder if all properties should be optional? I don't have this scenario today, but perhaps the frequencies could be encoded in fuses, but the voltages wouldn't be and so we might want to read out the frequencies for a fixed set of voltages. Of course, if there's nothing in the OPP node at all, it's not very useful, so perhaps some statement that at least one of the frequency/voltage/amperage properties should be present.

I am not sure. What we are trying to do (fill partially in DT and partially in platform), is a trick and not the right use of bindings.

Ideally whatever is passed in DT should be complete by itself and doesn't require platform to tweak it (which it can't). For example, the cpufreq-dt driver will try to initialize OPPs from the DT directly and wouldn't know about the platform tweaks. That can work eventually as platform will add OPPs for the same bindings before cpufreq driver will try to do, but that's a trick.

Quoted 3 lines

And then its all about frequency in the first place, and so marking that optional looks wrong. Probably not the right use of these bindings.

Ok then I won't be using these bindings on any of the new platforms I have where half the data is in one place, and half in another. But for some of Krait based platforms I have they should be useable.

Quoted 20 lines · Stephen Boyd

Quoted 19 lines · Viresh Kumar

Quoted 7 lines · Stephen Boyd

Also I wonder if all properties should be optional? I don't have this scenario today, but perhaps the frequencies could be encoded in fuses, but the voltages wouldn't be and so we might want to read out the frequencies for a fixed set of voltages. Of course, if there's nothing in the OPP node at all, it's not very useful, so perhaps some statement that at least one of the frequency/voltage/amperage properties should be present.

I am not sure. What we are trying to do (fill partially in DT and partially in platform), is a trick and not the right use of bindings.

Ideally whatever is passed in DT should be complete by itself and doesn't require platform to tweak it (which it can't). For example, the cpufreq-dt driver will try to initialize OPPs from the DT directly and wouldn't know about the platform tweaks. That can work eventually as platform will add OPPs for the same bindings before cpufreq driver will try to do, but that's a trick.

Quoted 7 lines

Quoted 3 lines

And then its all about frequency in the first place, and so marking that optional looks wrong. Probably not the right use of these bindings.

Ok then I won't be using these bindings on any of the new platforms I have where half the data is in one place, and half in another. But for some of Krait based platforms I have they should be useable.

You are not the only one, I have seen other requests (even for the existing bindings) to fill stuff partially in DT as they want freq to come from bootloader.

@Rob: What do you suggest for such platforms? Let them keep (ab)using old or new OPP DT bindings or create another binding to just pass on freq table?

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 eeprom) 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.

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

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

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

index 3b67a5c8d965..07959903ec32 100644
@@ -14,6 +14,9 @@ Devices supporting OPPs must set their "operating-points-v2" property with
 phandle to a OPP descriptor 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.
+
 
 * OPP Descriptor Node
 

Quoted 1 line · Viresh Kumar

(sort of an eeprom) and knowing characteristics of the SoC.

they are more like prom than eeprom in many instances.

With some SoCs like AM335x - thanks to some brain dead incompatible hardware design choices, this might end up as a big list or various OPP tables. but overall, I must prefer this approach as well.

Thanks for proposing this. will be great to see examples documented in bindings doc as well.

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 eeprom) 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.

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

---

Many platforms require to switch to a intermediate frequency before switching to a final frequency. Or they can switch to only particular OPPs from any OPP.

For these add another property in OPP-v2, 'opp-next'.

Refer to the bindings for more details.

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