* [PATCH V7 0/3] OPP: Introduce OPP (V2) bindings
@ 2015-06-04 16:20 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-04 16:20 UTC (permalink / raw)
To: Rafael Wysocki, rob.herring
Cc: linaro-kernel, linux-pm, arnd.bergmann, nm, broonie,
mike.turquette, sboyd, grant.likely, olof, Sudeep.Holla,
devicetree, viswanath.puttagunta, l.stach, thomas.petazzoni,
linux-arm-kernel, ta.omasab, kesavan.abhilash, khilman,
santosh.shilimkar, Viresh Kumar
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(-)
--
2.4.0
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 0/3] OPP: Introduce OPP (V2) bindings
@ 2015-06-04 16:20 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-04 16:20 UTC (permalink / raw)
To: linux-arm-kernel
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(-)
--
2.4.0
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings
2015-06-04 16:20 ` Viresh Kumar
@ 2015-06-04 16:20 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-04 16:20 UTC (permalink / raw)
To: Rafael Wysocki, rob.herring-QSEj5FYQhm4dnm+yROfE0A
Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A, nm-l0cyMroinI0,
broonie-DgEjT+Ai2ygdnm+yROfE0A,
mike.turquette-QSEj5FYQhm4dnm+yROfE0A,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, grant.likely-QSEj5FYQhm4dnm+yROfE0A,
olof-nZhT3qVonbNeoWH0uzbU5w, Sudeep.Holla-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
viswanath.puttagunta-QSEj5FYQhm4dnm+yROfE0A,
l.stach-bIcnvbaLZ9MEGnE8C9+IrQ,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ta.omasab-Re5JQEeQqe8AvxtiuMwx3w,
kesavan.abhilash-Re5JQEeQqe8AvxtiuMwx3w,
khilman-QSEj5FYQhm4dnm+yROfE0A,
santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA, 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.
We now have multiple versions of OPP binding and only one of them should
be used per device.
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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>;
+ };
+ };
+};
--
2.4.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings
@ 2015-06-04 16:20 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-04 16:20 UTC (permalink / raw)
To: linux-arm-kernel
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 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";
+ cpu-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";
+ 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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>;
+ };
+ };
+};
--
2.4.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-04 16:20 ` Viresh Kumar
@ 2015-06-04 16:20 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-04 16:20 UTC (permalink / raw)
To: Rafael Wysocki, rob.herring
Cc: linaro-kernel, linux-pm, arnd.bergmann, nm, broonie,
mike.turquette, sboyd, grant.likely, olof, Sudeep.Holla,
devicetree, viswanath.puttagunta, l.stach, thomas.petazzoni,
linux-arm-kernel, ta.omasab, kesavan.abhilash, khilman,
santosh.shilimkar, Viresh Kumar
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>;
+ ...
+ };
+ };
+};
--
2.4.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-04 16:20 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-04 16:20 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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>;
+ ...
+ };
+ };
+};
--
2.4.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-04 16:20 ` Viresh Kumar
@ 2015-06-04 16:20 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-04 16:20 UTC (permalink / raw)
To: Rafael Wysocki, rob.herring
Cc: linaro-kernel, linux-pm, arnd.bergmann, nm, broonie,
mike.turquette, sboyd, grant.likely, olof, Sudeep.Holla,
devicetree, viswanath.puttagunta, l.stach, thomas.petazzoni,
linux-arm-kernel, ta.omasab, kesavan.abhilash, khilman,
santosh.shilimkar, Viresh Kumar
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>;
--
2.4.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-04 16:20 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-04 16:20 UTC (permalink / raw)
To: linux-arm-kernel
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>;
--
2.4.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings
2015-06-04 16:20 ` Viresh Kumar
@ 2015-06-04 18:37 ` Stephen Boyd
-1 siblings, 0 replies; 56+ messages in thread
From: Stephen Boyd @ 2015-06-04 18:37 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, rob.herring, linaro-kernel, linux-pm,
arnd.bergmann, nm, broonie, mike.turquette, grant.likely, olof,
Sudeep.Holla, devicetree, viswanath.puttagunta, l.stach,
thomas.petazzoni, linux-arm-kernel, ta.omasab, kesavan.abhilash,
khilman, santosh.shilimkar
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>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings
@ 2015-06-04 18:37 ` Stephen Boyd
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Boyd @ 2015-06-04 18:37 UTC (permalink / raw)
To: linux-arm-kernel
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>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings
2015-06-04 18:37 ` Stephen Boyd
@ 2015-06-05 2:41 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-05 2:41 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rafael Wysocki, rob.herring, linaro-kernel, linux-pm,
arnd.bergmann, nm, broonie, mike.turquette, grant.likely, olof,
Sudeep.Holla, devicetree, viswanath.puttagunta, l.stach,
thomas.petazzoni, linux-arm-kernel, ta.omasab, kesavan.abhilash,
khilman, santosh.shilimkar
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 :)
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings
@ 2015-06-05 2:41 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-05 2:41 UTC (permalink / raw)
To: linux-arm-kernel
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 :)
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-04 16:20 ` Viresh Kumar
@ 2015-06-13 8:40 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-13 8:40 UTC (permalink / raw)
To: Rafael Wysocki, rob.herring
Cc: linaro-kernel, linux-pm, arnd.bergmann, nm, broonie,
mike.turquette, sboyd, grant.likely, olof, Sudeep.Holla,
devicetree, viswanath.puttagunta, l.stach, thomas.petazzoni,
linux-arm-kernel, ta.omasab, kesavan.abhilash, khilman,
santosh.shilimkar
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>;
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-13 8:40 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-13 8:40 UTC (permalink / raw)
To: linux-arm-kernel
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>;
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-13 8:40 ` Viresh Kumar
@ 2015-06-15 22:30 ` Rafael J. Wysocki
-1 siblings, 0 replies; 56+ messages in thread
From: Rafael J. Wysocki @ 2015-06-15 22:30 UTC (permalink / raw)
To: Viresh Kumar
Cc: rob.herring, linaro-kernel, linux-pm, arnd.bergmann, nm, broonie,
mike.turquette, sboyd, grant.likely, olof, Sudeep.Holla,
devicetree, viswanath.puttagunta, l.stach, thomas.petazzoni,
linux-arm-kernel, ta.omasab, kesavan.abhilash, khilman,
santosh.shilimkar
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>;
> 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>;
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-15 22:30 ` Rafael J. Wysocki
0 siblings, 0 replies; 56+ messages in thread
From: Rafael J. Wysocki @ 2015-06-15 22:30 UTC (permalink / raw)
To: linux-arm-kernel
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>;
> 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>;
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-04 16:20 ` Viresh Kumar
@ 2015-06-15 23:35 ` Rob Herring
-1 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-15 23:35 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Stephen Boyd, Grant Likely,
Olof Johansson, Sudeep Holla, devicetree@vger.kernel.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-15 23:35 ` Rob Herring
0 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-15 23:35 UTC (permalink / raw)
To: linux-arm-kernel
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 at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-15 23:35 ` Rob Herring
@ 2015-06-16 0:31 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-16 0:31 UTC (permalink / raw)
To: Rob Herring
Cc: Rafael Wysocki,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Nishanth Menon, Mark Brown, Mike Turquette, Stephen Boyd,
Grant Likely, Olof Johansson, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Thomas Abraham, Abhilash Kesavan, Kevin Hilman, Santosh
On 16 June 2015 at 05:05, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-16 0:31 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-16 0:31 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-16 0:31 ` Viresh Kumar
@ 2015-06-16 2:54 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-16 2:54 UTC (permalink / raw)
To: Rob Herring
Cc: Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Stephen Boyd, Grant Likely,
Olof Johansson, Sudeep Holla, devicetree@vger.kernel.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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>;
--
2.4.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-16 2:54 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-16 2:54 UTC (permalink / raw)
To: linux-arm-kernel
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>;
--
2.4.0
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings
2015-06-04 16:20 ` Viresh Kumar
@ 2015-06-16 13:34 ` Nishanth Menon
-1 siblings, 0 replies; 56+ messages in thread
From: Nishanth Menon @ 2015-06-16 13:34 UTC (permalink / raw)
To: Viresh Kumar, Rafael Wysocki, rob.herring
Cc: linaro-kernel, linux-pm, arnd.bergmann, broonie, mike.turquette,
sboyd, grant.likely, olof, Sudeep.Holla, devicetree,
viswanath.puttagunta, l.stach, thomas.petazzoni, linux-arm-kernel,
ta.omasab, kesavan.abhilash, khilman, santosh.shilimkar
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.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings
@ 2015-06-16 13:34 ` Nishanth Menon
0 siblings, 0 replies; 56+ messages in thread
From: Nishanth Menon @ 2015-06-16 13:34 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-16 2:54 ` Viresh Kumar
@ 2015-06-16 19:23 ` Rob Herring
-1 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-16 19:23 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Nishanth Menon, Mark Brown, Mike Turquette, Stephen Boyd,
Grant Likely, Olof Johansson, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Thomas Abraham, Abhilash Kesavan, Kevin Hilman, Santosh
On Mon, Jun 15, 2015 at 9:54 PM, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 16-06-15, 06:01, Viresh Kumar wrote:
>> On 16 June 2015 at 05:05, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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-l0cyMroinI0@public.gmane.org>
> Suggested-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> V7->V8:
> - opp-suspend is moved to OPPs instead of the table, and is bool now.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-16 19:23 ` Rob Herring
0 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-16 19:23 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-16 19:23 ` Rob Herring
@ 2015-06-16 21:21 ` Rafael J. Wysocki
-1 siblings, 0 replies; 56+ messages in thread
From: Rafael J. Wysocki @ 2015-06-16 21:21 UTC (permalink / raw)
To: Rob Herring
Cc: Viresh Kumar, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Stephen Boyd, Grant Likely,
Olof Johansson, Sudeep Holla, devicetree@vger.kernel.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-16 21:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 56+ messages in thread
From: Rafael J. Wysocki @ 2015-06-16 21:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-16 21:21 ` Rafael J. Wysocki
@ 2015-06-17 2:38 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-17 2:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rob Herring, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Stephen Boyd, Grant Likely,
Olof Johansson, Sudeep Holla, devicetree@vger.kernel.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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 :)
@Rob: Please Ack 2/3 as well :)
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-17 2:38 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-17 2:38 UTC (permalink / raw)
To: linux-arm-kernel
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 :)
@Rob: Please Ack 2/3 as well :)
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
2015-06-17 2:38 ` Viresh Kumar
@ 2015-06-17 9:38 ` Rafael J. Wysocki
-1 siblings, 0 replies; 56+ messages in thread
From: Rafael J. Wysocki @ 2015-06-17 9:38 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Rob Herring,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Nishanth Menon, Mark Brown, Mike Turquette, Stephen Boyd,
Grant Likely, Olof Johansson, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Thomas Abraham, Abhilash Kesavan, Kevin
On Wed, Jun 17, 2015 at 4:38 AM, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 3/3] OPP: Add binding for 'opp-suspend'
@ 2015-06-17 9:38 ` Rafael J. Wysocki
0 siblings, 0 replies; 56+ messages in thread
From: Rafael J. Wysocki @ 2015-06-17 9:38 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-04 16:20 ` Viresh Kumar
@ 2015-06-17 13:23 ` Rob Herring
-1 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-17 13:23 UTC (permalink / raw)
To: Viresh Kumar, Stephen Boyd
Cc: Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh Shilimkar
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-17 13:23 ` Rob Herring
0 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-17 13:23 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-17 13:23 ` Rob Herring
@ 2015-06-17 13:33 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-17 13:33 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Boyd, Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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.
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-17 13:33 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-17 13:33 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-17 13:33 ` Viresh Kumar
@ 2015-06-17 13:47 ` Rob Herring
-1 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-17 13:47 UTC (permalink / raw)
To: Viresh Kumar, Stephen Boyd
Cc: Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh Shilimkar
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-17 13:47 ` Rob Herring
0 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-17 13:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-17 13:47 ` Rob Herring
@ 2015-06-17 14:42 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-17 14:42 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Boyd, Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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.
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-17 14:42 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-17 14:42 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-17 13:47 ` Rob Herring
@ 2015-06-18 1:30 ` Stephen Boyd
-1 siblings, 0 replies; 56+ messages in thread
From: Stephen Boyd @ 2015-06-18 1:30 UTC (permalink / raw)
To: Rob Herring, Viresh Kumar
Cc: Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh Shilimkar
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.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-18 1:30 ` Stephen Boyd
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Boyd @ 2015-06-18 1:30 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-18 1:30 ` Stephen Boyd
@ 2015-06-18 2:25 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-18 2:25 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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?
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-18 2:25 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-18 2:25 UTC (permalink / raw)
To: linux-arm-kernel
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?
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-18 2:25 ` Viresh Kumar
@ 2015-06-18 2:50 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-18 2:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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>;
+ ...
+ };
+ };
+};
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-18 2:50 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-18 2:50 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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>;
+ ...
+ };
+ };
+};
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-18 2:25 ` Viresh Kumar
@ 2015-06-19 18:44 ` Stephen Boyd
-1 siblings, 0 replies; 56+ messages in thread
From: Stephen Boyd @ 2015-06-19 18:44 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rob Herring, Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-19 18:44 ` Stephen Boyd
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Boyd @ 2015-06-19 18:44 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-18 2:50 ` Viresh Kumar
@ 2015-06-19 18:47 ` Stephen Boyd
-1 siblings, 0 replies; 56+ messages in thread
From: Stephen Boyd @ 2015-06-19 18:47 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rob Herring, Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-19 18:47 ` Stephen Boyd
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Boyd @ 2015-06-19 18:47 UTC (permalink / raw)
To: linux-arm-kernel
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>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-19 18:47 ` Stephen Boyd
@ 2015-06-19 18:52 ` Rob Herring
-1 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-19 18:52 UTC (permalink / raw)
To: Stephen Boyd
Cc: Viresh Kumar, Rafael Wysocki,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Nishanth Menon, Mark Brown, Mike Turquette, Grant Likely,
Olof Johansson, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Thomas Abraham, Abhilash Kesavan, Kevin Hilman, Santosh
On Fri, Jun 19, 2015 at 1:47 PM, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Same question here.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-19 18:52 ` Rob Herring
0 siblings, 0 replies; 56+ messages in thread
From: Rob Herring @ 2015-06-19 18:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-19 18:44 ` Stephen Boyd
@ 2015-06-20 2:18 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-20 2:18 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, Rafael Wysocki, linaro-kernel@lists.linaro.org,
linux-pm@vger.kernel.org, Arnd Bergmann, Nishanth Menon,
Mark Brown, Mike Turquette, Grant Likely, Olof Johansson,
Sudeep Holla, devicetree@vger.kernel.org, Viswanath Puttagunta,
Lucas Stach, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Thomas Abraham,
Abhilash Kesavan, Kevin Hilman, Santosh
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.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-20 2:18 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-20 2:18 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
viresh
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
2015-06-19 18:52 ` Rob Herring
@ 2015-06-20 2:24 ` Viresh Kumar
-1 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-20 2:24 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Boyd, Rafael Wysocki,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Nishanth Menon, Mark Brown, Mike Turquette, Grant Likely,
Olof Johansson, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Viswanath Puttagunta, Lucas Stach, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Thomas Abraham, Abhilash Kesavan, Kevin Hilman, Santosh
On 19-06-15, 13:52, Rob Herring wrote:
> On Fri, Jun 19, 2015 at 1:47 PM, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> > But isn't this being removed? If it is removed, feel free to add
Sigh..
> > Reviewed-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks. And here is the final Acked version..
------------------------8<-----------------------
From: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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>;
+ ...
+ };
+ };
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
^ permalink raw reply related [flat|nested] 56+ messages in thread
* [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
@ 2015-06-20 2:24 ` Viresh Kumar
0 siblings, 0 replies; 56+ messages in thread
From: Viresh Kumar @ 2015-06-20 2:24 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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>;
+ ...
+ };
+ };
+};
^ permalink raw reply related [flat|nested] 56+ messages in thread
end of thread, other threads:[~2015-06-20 2:24 UTC | newest]
Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-04 16:20 [PATCH V7 0/3] OPP: Introduce OPP (V2) bindings Viresh Kumar
2015-06-04 16:20 ` Viresh Kumar
[not found] ` <cover.1433434659.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-04 16:20 ` [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings Viresh Kumar
2015-06-04 16:20 ` Viresh Kumar
2015-06-04 18:37 ` Stephen Boyd
2015-06-04 18:37 ` Stephen Boyd
2015-06-05 2:41 ` Viresh Kumar
2015-06-05 2:41 ` Viresh Kumar
2015-06-16 13:34 ` Nishanth Menon
2015-06-16 13:34 ` Nishanth Menon
2015-06-04 16:20 ` [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT Viresh Kumar
2015-06-04 16:20 ` Viresh Kumar
2015-06-17 13:23 ` Rob Herring
2015-06-17 13:23 ` Rob Herring
2015-06-17 13:33 ` Viresh Kumar
2015-06-17 13:33 ` Viresh Kumar
2015-06-17 13:47 ` Rob Herring
2015-06-17 13:47 ` Rob Herring
2015-06-17 14:42 ` Viresh Kumar
2015-06-17 14:42 ` Viresh Kumar
2015-06-18 1:30 ` Stephen Boyd
2015-06-18 1:30 ` Stephen Boyd
2015-06-18 2:25 ` Viresh Kumar
2015-06-18 2:25 ` Viresh Kumar
2015-06-18 2:50 ` Viresh Kumar
2015-06-18 2:50 ` Viresh Kumar
2015-06-19 18:47 ` Stephen Boyd
2015-06-19 18:47 ` Stephen Boyd
[not found] ` <20150619184747.GD22132-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-06-19 18:52 ` Rob Herring
2015-06-19 18:52 ` Rob Herring
[not found] ` <CAL_JsqJfWDO4r_FP6xHSxRkMM-pSnbEUB=d9Gj6mhvPY+ouLxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-20 2:24 ` Viresh Kumar
2015-06-20 2:24 ` Viresh Kumar
2015-06-19 18:44 ` Stephen Boyd
2015-06-19 18:44 ` Stephen Boyd
2015-06-20 2:18 ` Viresh Kumar
2015-06-20 2:18 ` Viresh Kumar
2015-06-04 16:20 ` [PATCH V7 3/3] OPP: Add binding for 'opp-suspend' Viresh Kumar
2015-06-04 16:20 ` Viresh Kumar
2015-06-13 8:40 ` Viresh Kumar
2015-06-13 8:40 ` Viresh Kumar
2015-06-15 22:30 ` Rafael J. Wysocki
2015-06-15 22:30 ` Rafael J. Wysocki
2015-06-15 23:35 ` Rob Herring
2015-06-15 23:35 ` Rob Herring
[not found] ` <CAL_JsqJb4P2Z2esgm5ffjWV37MU2KUF4gBdUpwSV8+21iTD1Bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-16 0:31 ` Viresh Kumar
2015-06-16 0:31 ` Viresh Kumar
2015-06-16 2:54 ` Viresh Kumar
2015-06-16 2:54 ` Viresh Kumar
2015-06-16 19:23 ` Rob Herring
2015-06-16 19:23 ` Rob Herring
2015-06-16 21:21 ` Rafael J. Wysocki
2015-06-16 21:21 ` Rafael J. Wysocki
2015-06-17 2:38 ` Viresh Kumar
2015-06-17 2:38 ` Viresh Kumar
2015-06-17 9:38 ` Rafael J. Wysocki
2015-06-17 9:38 ` Rafael J. Wysocki
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.