Hi,
V6->V7: - s/opp-supply/cpu-supply (Stephen B)
V5->V6: - Acks/RBY from Rob and Nishanth added - Lots of rewording suggested by Nishanth - OPP Descriptor node is named OPP Table node now and so 'opp' is replaced by 'opp_table' in examples, as suggested by Nishanth. - OPP entries are named as 'oppX' instead of 'entry*' as suggested by Nishanth. - Phandles to slow and fast OPPs in 2/3 are named appropriately.
V4->V5: - opp-microamp fixed and rewritten as per Mark's suggestions. - shared-opp renamed as opp-shared, as that's the convention for other properties. - Dropped "[V4 3/3] OPP: Add 'opp-next' in operating-points-v2 bindings" as that was NAK'd by Mike T.. - Added [V5 3/3] based on Nishanth's suggestions. - Added an example for 2/3, multiple OPP nodes. - Other minor formatting.. - Existing binding: "operating-points" isn't deprecated now as platforms looking for simple bindings should be allowed to use them. - opp-khz is changed to opp-hz, examples updated. - turbo-mode explained
V3->V4: - Dropped code changes as we are still concerned about bindings. - separated out into three patches, some of which might be NAK'd. :) - The first patch presents basic OPP stuff that was reviewed earlier. It also has support for multiple regulators, with values for both current and voltage. - Second patch is based on a special concern that Stephen had about multiple OPP tables, one of which the parsing code will select at runtime. - Third one separates out 'opp-next' or Intermediate freq support as Mike T. had few concerns over it. He wanted the clock driver to take care of this and so do not want it to be passed by DT and used by cpufreq. Also, there were concerns like the platform may not want to choose intermediate frequency as a target frequency for longer runs, which wasn't prevented in earlier bindings. And so it is kept separate to be NAK'd quietly, without much disturbances.
---------------x-------------------x------------------------
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 patchset 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.
Viresh Kumar (3): OPP: Add new bindings to address shortcomings of existing bindings OPP: Allow multiple OPP tables to be passed via DT OPP: Add binding for 'opp-suspend'
Documentation/devicetree/bindings/power/opp.txt | 439 +++++++++++++++++++++++- 1 file changed, 435 insertions(+), 4 deletions(-)
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 robh@kernel.org Signed-off-by: Viresh Kumar viresh.kumar@linaro.org --- Documentation/devicetree/bindings/power/opp.txt | 381 +++++++++++++++++++++++- 1 file changed, 377 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 74499e5033fc..259bf00edf7d 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -1,8 +1,19 @@ -* 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 combinations and some implementations +have the liberty of choosing these. These combinations 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. + +This document contain multiple versions of OPP binding and only one of them +should be used per device. + +Binding 1: operating-points +============================ + +This binding only supports voltage-frequency pairs.
Properties: - operating-points: An array of 2-tuples items, and each item consists @@ -23,3 +34,365 @@ cpu@0 { 198000 850000 >; }; + + +Binding 2: operating-points-v2 +============================ + +* Property: operating-points-v2 + +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. + +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>". + +* OPP Table 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 + combinations. Their name isn't significant but their phandle can be used to + reference an OPP. + +Optional properties: +- 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, + but they share OPP tables. + + +* OPP Node + +This defines voltage-current-frequency combinations along with other related +properties. + +Required properties: +- opp-hz: Frequency in Hz + +Optional properties: +- opp-microvolt: voltage in micro Volts. + + 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: The maximum current drawn by the device in microamperes + considering system specific parameters (such as transients, process, aging, + maximum operating temperature range etc.) as necessary. This may be 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. + +- 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. Turbo mode is + available on some platforms, where the device can run over its operating + frequency for a short duration of time limited by the device's power, current + and thermal limits. + +- status: Marks the node enabled/disabled. + +Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together. + +/ { + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + compatible = "arm,cortex-a9"; + reg = <0>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cpu0_opp_table>; + }; + + cpu@1 { + compatible = "arm,cortex-a9"; + reg = <1>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cpu0_opp_table>; + }; + }; + + cpu0_opp_table: opp_table0 { + compatible = "operating-points-v2"; + opp-shared; + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>; + opp-microamp = <70000>; + clock-latency-ns = <300000>; + }; + opp01 { + opp-hz = <1100000000>; + opp-microvolt = <980000 1000000 1010000>; + opp-microamp = <80000>; + clock-latency-ns = <310000>; + }; + opp02 { + opp-hz = <1200000000>; + 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@0 { + compatible = "qcom,krait"; + reg = <0>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cpu_opp_table>; + }; + + cpu@1 { + compatible = "qcom,krait"; + reg = <1>; + next-level-cache = <&L2>; + clocks = <&clk_controller 1>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply1>; + operating-points-v2 = <&cpu_opp_table>; + }; + + cpu@2 { + compatible = "qcom,krait"; + reg = <2>; + next-level-cache = <&L2>; + clocks = <&clk_controller 2>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply2>; + operating-points-v2 = <&cpu_opp_table>; + }; + + cpu@3 { + compatible = "qcom,krait"; + reg = <3>; + next-level-cache = <&L2>; + clocks = <&clk_controller 3>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply3>; + operating-points-v2 = <&cpu_opp_table>; + }; + }; + + cpu_opp_table: opp_table { + compatible = "operating-points-v2"; + + /* + * Missing opp-shared property means CPUs switch DVFS states + * independently. + */ + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>; + opp-microamp = <70000>; + clock-latency-ns = <300000>; + }; + opp01 { + opp-hz = <1100000000>; + opp-microvolt = <980000 1000000 1010000>; + opp-microamp = <80000>; + clock-latency-ns = <310000>; + }; + opp02 { + opp-hz = <1200000000>; + 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@0 { + compatible = "arm,cortex-a7"; + reg = <0>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cluster0_opp>; + }; + + cpu@1 { + compatible = "arm,cortex-a7"; + reg = <1>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cluster0_opp>; + }; + + cpu@100 { + compatible = "arm,cortex-a15"; + reg = <100>; + next-level-cache = <&L2>; + clocks = <&clk_controller 1>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply1>; + operating-points-v2 = <&cluster1_opp>; + }; + + cpu@101 { + compatible = "arm,cortex-a15"; + reg = <101>; + next-level-cache = <&L2>; + clocks = <&clk_controller 1>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply1>; + operating-points-v2 = <&cluster1_opp>; + }; + }; + + cluster0_opp: opp_table0 { + compatible = "operating-points-v2"; + opp-shared; + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>; + opp-microamp = <70000>; + clock-latency-ns = <300000>; + }; + opp01 { + opp-hz = <1100000000>; + opp-microvolt = <980000 1000000 1010000>; + opp-microamp = <80000>; + clock-latency-ns = <310000>; + }; + opp02 { + opp-hz = <1200000000>; + opp-microvolt = <1025000>; + opp-microamp = <90000>; + clock-latency-ns = <290000>; + turbo-mode; + }; + }; + + cluster1_opp: opp_table1 { + compatible = "operating-points-v2"; + opp-shared; + + opp10 { + opp-hz = <1300000000>; + opp-microvolt = <1045000 1050000 1055000>; + opp-microamp = <95000>; + clock-latency-ns = <400000>; + }; + opp11 { + opp-hz = <1400000000>; + opp-microvolt = <1075000>; + opp-microamp = <100000>; + clock-latency-ns = <400000>; + }; + opp12 { + opp-hz = <1500000000>; + opp-microvolt = <1010000 1100000 1110000>; + opp-microamp = <95000>; + clock-latency-ns = <400000>; + turbo-mode; + }; + }; +}; + +Example 4: Handling multiple regulators + +/ { + cpus { + cpu@0 { + compatible = "arm,cortex-a7"; + ... + + cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>; + operating-points-v2 = <&cpu0_opp_table>; + }; + }; + + cpu0_opp_table: opp_table0 { + compatible = "operating-points-v2"; + opp-shared; + + opp00 { + opp-hz = <1000000000>; + 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 */ + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>, /* Supply 0 */ + <960000 965000 975000>, /* Supply 1 */ + <960000 965000 975000>; /* Supply 2 */ + opp-microamp = <70000>, /* Supply 0 */ + <70000>, /* Supply 1 */ + <70000>; /* Supply 2 */ + clock-latency-ns = <300000>; + }; + + /* OR */ + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>, /* Supply 0 */ + <960000 965000 975000>, /* Supply 1 */ + <960000 965000 975000>; /* Supply 2 */ + opp-microamp = <70000>, /* Supply 0 */ + <0>, /* Supply 1 doesn't need this */ + <70000>; /* Supply 2 */ + clock-latency-ns = <300000>; + }; + }; +};
On 06/04, Viresh Kumar wrote:
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 robh@kernel.org Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
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 sboyd@codeaurora.org
On 04-06-15, 11:37, Stephen Boyd wrote:
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.
I can understand your concern here, but getting everything working on the first attempt would be difficult to write/review.. There will at least be 5-7 patches just for getting the very basic v2 bindings coded. And so we can get all that coded slowly and steadily.
But for now,
Reviewed-by: Stephen Boyd sboyd@codeaurora.org
Thanks. Finally :)
On 06/04/2015 11:20 AM, Viresh Kumar wrote:
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 robh@kernel.org Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
I thought I had acked the patch 1 of the series as well in the list, but looks like I have'nt.. So, for the record..
Acked-by: Nishanth Menon nm@ti.com
Thanks for doing this.
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 nm@ti.com Reviewed-by: Stephen Boyd sboyd@codeaurora.org Signed-off-by: Viresh Kumar viresh.kumar@linaro.org --- Documentation/devicetree/bindings/power/opp.txt | 52 +++++++++++++++++++++++++ 1 file changed, 52 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 259bf00edf7d..2938c52dbf84 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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 }; }; }; + +Example 5: Multiple OPP tables + +/ { + cpus { + cpu@0 { + compatible = "arm,cortex-a7"; + ... + + cpu-supply = <&cpu_supply> + operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>; + }; + }; + + cpu0_opp_table_slow: opp_table_slow { + compatible = "operating-points-v2"; + opp-name = "slow"; + opp-shared; + + opp00 { + opp-hz = <600000000>; + ... + }; + + opp01 { + opp-hz = <800000000>; + ... + }; + }; + + cpu0_opp_table_fast: opp_table_fast { + compatible = "operating-points-v2"; + opp-name = "fast"; + opp-shared; + + opp10 { + opp-hz = <1000000000>; + ... + }; + + opp11 { + opp-hz = <1100000000>; + ... + }; + }; +};
On Thu, Jun 4, 2015 at 11:20 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
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 nm@ti.com Reviewed-by: Stephen Boyd sboyd@codeaurora.org Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
Documentation/devicetree/bindings/power/opp.txt | 52 +++++++++++++++++++++++++ 1 file changed, 52 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 259bf00edf7d..2938c52dbf84 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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 }; }; };
+Example 5: Multiple OPP tables
+/ {
cpus {cpu@0 {compatible = "arm,cortex-a7";...cpu-supply = <&cpu_supply>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?).
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?
Rob
On 17-06-15, 08:23, Rob Herring wrote:
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:
+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.
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.
On Wed, Jun 17, 2015 at 8:33 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 17-06-15, 08:23, Rob Herring wrote:
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:
+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.
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.
Rob
On 17-06-15, 08:47, Rob Herring wrote:
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 agree that we should have used this..
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.
Good that you told me to stop :)
You can also use "status" to disable specific tables rather than removing from the list.
Hmmm, right. That's far better.
On 06/17/2015 06:47 AM, Rob Herring wrote:
On Wed, Jun 17, 2015 at 8:33 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 17-06-15, 08:23, Rob Herring wrote:
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:
+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.
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? It would make the parsing code slightly more complicated because it needs to look for 2 or 3 properties instead of a name property though. Or would having different node names be acceptable? That would avoid this list of strings.
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.
On 17-06-15, 18:30, Stephen Boyd wrote:
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.
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.
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.
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?
On 18-06-15, 07:55, Viresh Kumar wrote:
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 viresh.kumar@linaro.org 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 viresh.kumar@linaro.org --- Documentation/devicetree/bindings/power/opp.txt | 63 +++++++++++++++++++++++++ 1 file changed, 63 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 259bf00edf7d..72ccacaac9c9 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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 @@ -63,11 +74,16 @@ 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, but they share OPP tables.
+- status: Marks the OPP table enabled/disabled. +
* OPP Node
@@ -396,3 +412,50 @@ Example 4: Handling multiple regulators }; }; }; + +Example 5: Multiple OPP tables + +/ { + cpus { + cpu@0 { + compatible = "arm,cortex-a7"; + ... + + cpu-supply = <&cpu_supply> + operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>; + operating-points-v2-names = "slow", "fast"; + }; + }; + + cpu0_opp_table_slow: opp_table_slow { + compatible = "operating-points-v2"; + status = "okay"; + opp-shared; + + opp00 { + opp-hz = <600000000>; + ... + }; + + opp01 { + opp-hz = <800000000>; + ... + }; + }; + + cpu0_opp_table_fast: opp_table_fast { + compatible = "operating-points-v2"; + status = "okay"; + opp-shared; + + opp10 { + opp-hz = <1000000000>; + ... + }; + + opp11 { + opp-hz = <1100000000>; + ... + }; + }; +};
On 06/18, Viresh Kumar wrote:
On 18-06-15, 07:55, Viresh Kumar wrote:
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 viresh.kumar@linaro.org 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 viresh.kumar@linaro.org
Looks mostly ok..
Documentation/devicetree/bindings/power/opp.txt | 63 +++++++++++++++++++++++++ 1 file changed, 63 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 259bf00edf7d..72ccacaac9c9 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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 @@ -63,11 +74,16 @@ 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.
But isn't this being removed? If it is removed, feel free to add
Reviewed-by: Stephen Boyd sboyd@codeaurora.org
On Fri, Jun 19, 2015 at 1:47 PM, Stephen Boyd sboyd@codeaurora.org wrote:
On 06/18, Viresh Kumar wrote:
On 18-06-15, 07:55, Viresh Kumar wrote:
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 viresh.kumar@linaro.org 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 viresh.kumar@linaro.org
Looks mostly ok..
Documentation/devicetree/bindings/power/opp.txt | 63 +++++++++++++++++++++++++ 1 file changed, 63 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 259bf00edf7d..72ccacaac9c9 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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
Let's drop v2. We know it only applies to v2.
- 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.
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 sboyd@codeaurora.org
Same question here.
Acked-by: Rob Herring robh@kernel.org
Rob
On 19-06-15, 13:52, Rob Herring wrote:
On Fri, Jun 19, 2015 at 1:47 PM, Stephen Boyd sboyd@codeaurora.org wrote:
But isn't this being removed? If it is removed, feel free to add
Sigh..
Reviewed-by: Stephen Boyd sboyd@codeaurora.org
Acked-by: Rob Herring robh@kernel.org
Thanks. And here is the final Acked version..
------------------------8<-----------------------
From: Viresh Kumar viresh.kumar@linaro.org 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.
Reviewed-by: Stephen Boyd sboyd@codeaurora.org Acked-by: Rob Herring robh@kernel.org Signed-off-by: Viresh Kumar viresh.kumar@linaro.org --- Documentation/devicetree/bindings/power/opp.txt | 60 +++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 259bf00edf7d..3d5d32ca0f97 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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-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-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 @@ -68,6 +79,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.
+- status: Marks the OPP table enabled/disabled. +
* OPP Node
@@ -396,3 +409,50 @@ Example 4: Handling multiple regulators }; }; }; + +Example 5: Multiple OPP tables + +/ { + cpus { + cpu@0 { + compatible = "arm,cortex-a7"; + ... + + cpu-supply = <&cpu_supply> + operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>; + operating-points-names = "slow", "fast"; + }; + }; + + cpu0_opp_table_slow: opp_table_slow { + compatible = "operating-points-v2"; + status = "okay"; + opp-shared; + + opp00 { + opp-hz = <600000000>; + ... + }; + + opp01 { + opp-hz = <800000000>; + ... + }; + }; + + cpu0_opp_table_fast: opp_table_fast { + compatible = "operating-points-v2"; + status = "okay"; + opp-shared; + + opp10 { + opp-hz = <1000000000>; + ... + }; + + opp11 { + opp-hz = <1100000000>; + ... + }; + }; +};
On 06/18, Viresh Kumar wrote:
On 17-06-15, 18:30, Stephen Boyd wrote:
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.
Yes.
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. :)
As am I.
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.
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.
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?
This is a reply to Rob's question about fixed ordering without a names property. That's unlikely to work out for qcom chips.
On 19-06-15, 11:44, Stephen Boyd wrote:
On 06/18, Viresh Kumar wrote:
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.
So what I wrote about the string being same for all CPUs, is valid only to CPUs sharing clock line and hence OPPs. If there are CPUs with independent lines, like in Krait, then the CPUs are free to choose whatever name they want for the OPP tables, even if they are sharing the same tables.
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 nm@ti.com Suggested-by: Nishanth Menon nm@ti.com Signed-off-by: Viresh Kumar viresh.kumar@linaro.org --- Documentation/devicetree/bindings/power/opp.txt | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 2938c52dbf84..6c245d87dd50 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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 04-06-15, 21:50, Viresh Kumar wrote:
opp-suspend = <&suspend_opp>;
opp00 {
suspend-opp: opp00 {
Minor nit, s/suspend-opp/suspend_opp
and here is updated patch
From: Viresh Kumar viresh.kumar@linaro.org 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 nm@ti.com Suggested-by: Nishanth Menon nm@ti.com Signed-off-by: Viresh Kumar viresh.kumar@linaro.org --- Documentation/devicetree/bindings/power/opp.txt | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 2938c52dbf84..29f115d26f7d 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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 Saturday, June 13, 2015 02:10:23 PM Viresh Kumar wrote:
On 04-06-15, 21:50, Viresh Kumar wrote:
opp-suspend = <&suspend_opp>;
opp00 {
suspend-opp: opp00 {Minor nit, s/suspend-opp/suspend_opp
and here is updated patch
From: Viresh Kumar viresh.kumar@linaro.org 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 nm@ti.com Suggested-by: Nishanth Menon nm@ti.com Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
Well, I'm kind of wondering what else has been overlooked here.
Anyway, if I'm supposed to apply this series, I need an ACK from at least one person listed as an "OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" maintainer. Preferably from Rob.
Documentation/devicetree/bindings/power/opp.txt | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 2938c52dbf84..29f115d26f7d 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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>;
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>;
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>;
opp10 {
suspend_opp: opp10 { opp-hz = <1300000000>; opp-microvolt = <1045000 1050000 1055000>; opp-microamp = <95000>;
On Thu, Jun 4, 2015 at 11:20 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
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 nm@ti.com Suggested-by: Nishanth Menon nm@ti.com Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
Documentation/devicetree/bindings/power/opp.txt | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 2938c52dbf84..6c245d87dd50 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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.
I would just do a bool property in the OPP you want.
Rob
- 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 16 June 2015 at 05:05, Rob Herring robherring2@gmail.com wrote:
+- 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.
But I would like to explain why I did it this way. Nishanth asked the same thing earlier and now he looks convinced :)
There can only be one OPP that can be selected during suspend. Allowing more than one OPP to select this property doesn't look like the right thing to me. In that case we have to make a rule that the first OPP in the table will be selected or error out in that case.
And I thought that this is property of the table, instead of each OPP. For example, in code this will waste lots of space if we choose such a field in individual OPPs, and we will always keep it in the OPP-table thing..
But then this is DT :)
I will wait for your reply Rob on this, and then will send an update. Thanks.
On 16-06-15, 06:01, Viresh Kumar wrote:
On 16 June 2015 at 05:05, Rob Herring robherring2@gmail.com wrote:
+- 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 viresh.kumar@linaro.org 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 nm@ti.com Suggested-by: Nishanth Menon nm@ti.com Signed-off-by: Viresh Kumar viresh.kumar@linaro.org --- 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(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 2938c52dbf84..2d4291127003 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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>;
On Mon, Jun 15, 2015 at 9:54 PM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 16-06-15, 06:01, Viresh Kumar wrote:
On 16 June 2015 at 05:05, Rob Herring robherring2@gmail.com wrote:
+- 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 viresh.kumar@linaro.org 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 nm@ti.com Suggested-by: Nishanth Menon nm@ti.com Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
V7->V8:
- opp-suspend is moved to OPPs instead of the table, and is bool now.
Acked-by: Rob Herring robh@kernel.org
Documentation/devicetree/bindings/power/opp.txt | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 2938c52dbf84..2d4291127003 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -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
On Tuesday, June 16, 2015 02:23:23 PM Rob Herring wrote:
On Mon, Jun 15, 2015 at 9:54 PM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 16-06-15, 06:01, Viresh Kumar wrote:
On 16 June 2015 at 05:05, Rob Herring robherring2@gmail.com wrote:
+- 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 viresh.kumar@linaro.org 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 nm@ti.com Suggested-by: Nishanth Menon nm@ti.com Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
V7->V8:
- opp-suspend is moved to OPPs instead of the table, and is bool now.
Acked-by: Rob Herring robh@kernel.org
Thanks!
Does your ACK also apply to patches [1-2/3] in this series?
Rafael
On Wed, Jun 17, 2015 at 4:38 AM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 16-06-15, 23:21, Rafael J. Wysocki wrote:
Does your ACK also apply to patches [1-2/3] in this series?
His RBY tag is already present for 1/3 :)
Yes, it is, sorry for overlooking that.
linaro-kernel@lists.linaro.org
-
Nishanth Menon -
Rafael J. Wysocki -
Rafael J. Wysocki -
Rob Herring -
Stephen Boyd -
Viresh Kumar