OPP: Introduce OPP (V2) bindings
v6 cover OPP: Introduce OPP (V2) bindings
Hi,
V5 got some more review comments, Acks, etc.. and they are all updated in V6.
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(-)
Signature · 1 line
2.4.0
PATCH v6 1/3 OPP: Add new bindings to address shortcomings of existing bindings
Current OPP (Operating performance point) device tree bindings have been insufficient due to the inflexible nature of the original bindings. Over time, we have realized that Operating Performance Point definitions and usage is varied depending on the SoC and a "single size (just frequency, voltage) fits all" model which the original bindings attempted and failed.
The proposed next generation of the bindings addresses by providing a expandable binding for OPPs and introduces the following common shortcomings seen with the original bindings:
- Getting clock/voltage/current rails sharing information between CPUs. Shared by all cores vs independent clock per core vs shared clock per cluster.
- Support for specifying current levels along with voltages.
- Support for multiple regulators.
- Support for turbo modes.
- Other per OPP settings: transition latencies, disabled status, etc.?
- Expandability of OPPs in future.
This patch introduces new bindings "operating-points-v2" to get these problems solved. Refer to the bindings for more details.
We now have multiple versions of OPP binding and only one of them should be used per device.
--- Documentation/devicetree/bindings/power/opp.txt | 381 +++++++++++++++++++++++- 1 file changed, 377 insertions(+), 4 deletions(-)
Documentation/devicetree/bindings/power/opp.txt +377 -4
@@ -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 at 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 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_table>; + }; + + 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_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 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 = <&cpu_opp_table>; + }; + + 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 = <&cpu_opp_table>; + }; + + 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 = <&cpu_opp_table>; + }; + + 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 = <&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 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: 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 at 0 { + compatible = "arm,cortex-a7"; + ... + + opp-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>; + }; + }; +};
Signature · 1 line
2.4.0
PATCH v6 1/3 OPP: Add new bindings to address shortcomings of existing bindings
Quoted 28 lines · Viresh Kumar
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.
Quoted 6 lines
We now have multiple versions of OPP binding and only one of them should be used per device.
Reviewed-by Rob Herring <[email protected]>Signed-off-by Viresh Kumar <[email protected]>---
It looks pretty good. Just one question below on the regulator stuff. Also, is there already code written to handle these new bindings in the OPP library? If not, it would be good to write some to flush out any problems that may be lurking in actual implementation.
Quoted 5 lines
Documentation/devicetree/bindings/power/opp.txt +5
-0+ +Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together. + +/ { + cpus {
Documentation/devicetree/bindings/power/opp.txt cpu at 0 { · line 125
Quoted 10 lines
Documentation/devicetree/bindings/power/opp.txt +10
-0+ #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>;
opp-supply isn't mentioned anywhere. Is that intentional? Is it supposed to be cpu-supply still? It isn't clear to me from the previous discussion where this all ended up, but I'm not sure how the in-kernel API is going to match up regulators with OPPs. I mean, how are we going to ask the OPP library what the min/max/target voltage is at a particular frequency when we have multiple regulators? Is that some string based interface?
dev_pm_opp_get_voltage(name, &target, &min, &max);
Or a regulator pointer interface?
dev_pm_opp_get_voltage(regulator, &target, &min, &max);
Or something else? Does this mean the OPP library is going to get the CPU device to request the opp-supply from the CPU node? Furthermore, why don't we care about opp-clocks? Are clocks somehow special?
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH v6 1/3 OPP: Add new bindings to address shortcomings of existing bindings
Quoted 6 lines · Stephen Boyd
Review
Quoted 1 line · Viresh Kumar
(quoted diff) +1
-0+ opp-supply = <&cpu_supply0>;opp-supply isn't mentioned anywhere. Is that intentional? Is it supposed to be cpu-supply still? It isn't clear to me from the
I'm also a bit worried about the naming here - regulator supplies should
always reflect the name of the supply in the hardware and it seems
unlikely that this is one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150602/a90a37b2/attachment.sig>
PATCH v6 1/3 OPP: Add new bindings to address shortcomings of existing bindings
In reply to Stephen BoydQuoted 4 lines · Stephen Boyd
Also, is there already code written to handle these new bindings in the OPP library? If not, it would be good to write some to flush out any problems that may be lurking in actual implementation.
I had written code earlier for V2 or something, but then we went back to the improvements in bindings and I stopped writing code for it.
http://marc.info/?i=cover.1423642246.git.viresh.kumar%40linaro.org
But that just requires to be updated a bit now. Will do that once I am sure the bindings are all good now, with all Acks and RBYs.
Quoted 9 lines
Quoted 9 lines
Documentation/devicetree/bindings/power/opp.txt +9
-0+ +Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together. + +/ { + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu at 0 {
Quoted 8 lines
Documentation/devicetree/bindings/power/opp.txt cpu at 0 { · line 125
Quoted 6 lines
Documentation/devicetree/bindings/power/opp.txt +6
-0+ compatible = "arm,cortex-a9"; + reg = <0>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + opp-supply = <&cpu_supply0>;opp-supply isn't mentioned anywhere. Is that intentional? Is it
This should have been 'cpu-supply' instead.
Quoted 1 line
supposed to be cpu-supply still?
Yes.
Quoted 7 lines
It isn't clear to me from the
previous discussion where this all ended up, but I'm not sure how the in-kernel API is going to match up regulators with OPPs. I mean, how are we going to ask the OPP library what the min/max/target voltage is at a particular frequency when we have multiple regulators? Is that some string based interface?
Quoted 5 lines
dev_pm_opp_get_voltage(name, &target, &min, &max);Or a regulator pointer interface?
dev_pm_opp_get_voltage(regulator, &target, &min, &max);
Probably this.
Quoted 2 lines
Or something else? Does this mean the OPP library is going to get the CPU device to request the opp-supply from the CPU node?
Maybe yes. That will clarify more with more code in place.
Quoted 2 lines
Furthermore, why don't we care about opp-clocks? Are clocks somehow special?
There shouldn't be opp-supply in the first place and so no need of opp-clocks as well.
Signature · 1 line
viresh
PATCH v6 2/3 OPP: Allow multiple OPP tables to be passed via DT
In reply to Viresh KumarOn 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.
--- Documentation/devicetree/bindings/power/opp.txt | 52 +++++++++++++++++++++++++ 1 file changed, 52 insertions(+)
Documentation/devicetree/bindings/power/opp.txt +52 -0
@@ -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 at 0 { + compatible = "arm,cortex-a7"; + ... + + opp-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>; + ... + }; + }; +};
Signature · 1 line
2.4.0
PATCH v6 3/3 OPP: Add binding for 'opp-suspend'
In reply to Viresh KumarOn 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.
--- Documentation/devicetree/bindings/power/opp.txt | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
Documentation/devicetree/bindings/power/opp.txt +10 -4
@@ -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>;
Signature · 1 line
2.4.0