| Message ID | 20150618025034.GB28820@linux (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 06/18, Viresh Kumar wrote: > On 18-06-15, 07:55, Viresh Kumar wrote: > > Why do you think so? For me the operating-points-v2-names property > > will be present in CPU node (as there is no OPP node which can have > > it) and so every CPU is free to choose what it wants to. > > So, I had something like this in mind: > > From: Viresh Kumar <viresh.kumar@linaro.org> > Date: Thu, 30 Apr 2015 17:38:00 +0530 > Subject: [PATCH] OPP: Allow multiple OPP tables to be passed via DT > > On some platforms (Like Qualcomm's SoCs), it is not decided until > runtime on what OPPs to use. The OPP tables can be fixed at compile > time, but which table to use is found out only after reading some efuses > (sort of an prom) and knowing characteristics of the SoC. > > To support such platform we need to pass multiple OPP tables per device > and hardware should be able to choose one and only one table out of > those. > > Update operating-points-v2 bindings to support that. > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Looks mostly ok.. > --- > Documentation/devicetree/bindings/power/opp.txt | 63 +++++++++++++++++++++++++ > 1 file changed, 63 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt > index 259bf00edf7d..72ccacaac9c9 100644 > --- a/Documentation/devicetree/bindings/power/opp.txt > +++ b/Documentation/devicetree/bindings/power/opp.txt > @@ -45,10 +45,21 @@ Devices supporting OPPs must set their "operating-points-v2" property with > phandle to a OPP table in their DT node. The OPP core will use this phandle to > find the operating points for the device. > > +Devices may want to choose OPP tables at runtime and so can provide a list of > +phandles here. But only *one* of them should be chosen at runtime. This must be > +accompanied by a corresponding "operating-points-v2-names" property, to uniquely > +identify the OPP tables. > + > If required, this can be extended for SoC vendor specfic bindings. Such bindings > should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt > and should have a compatible description like: "operating-points-v2-<vendor>". > > +Optional properties: > +- operating-points-v2-names: Names of OPP tables (required if multiple OPP > + tables are present), to uniquely identify them. The same list must be present > + for all the CPUs which are sharing clock/voltage rails and hence the OPP > + tables. > + > * OPP Table Node > > This describes the OPPs belonging to a device. This node can have following > @@ -63,11 +74,16 @@ This describes the OPPs belonging to a device. This node can have following > reference an OPP. > > Optional properties: > +- opp-name: Name of the OPP table, to uniquely identify it if more than one OPP > + table is supplied in "operating-points-v2" property of device. > + But isn't this being removed? If it is removed, feel free to add Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
On Fri, Jun 19, 2015 at 1:47 PM, Stephen Boyd <sboyd@codeaurora.org> wrote: > On 06/18, Viresh Kumar wrote: >> On 18-06-15, 07:55, Viresh Kumar wrote: >> > Why do you think so? For me the operating-points-v2-names property >> > will be present in CPU node (as there is no OPP node which can have >> > it) and so every CPU is free to choose what it wants to. >> >> So, I had something like this in mind: >> >> From: Viresh Kumar <viresh.kumar@linaro.org> >> Date: Thu, 30 Apr 2015 17:38:00 +0530 >> Subject: [PATCH] OPP: Allow multiple OPP tables to be passed via DT >> >> On some platforms (Like Qualcomm's SoCs), it is not decided until >> runtime on what OPPs to use. The OPP tables can be fixed at compile >> time, but which table to use is found out only after reading some efuses >> (sort of an prom) and knowing characteristics of the SoC. >> >> To support such platform we need to pass multiple OPP tables per device >> and hardware should be able to choose one and only one table out of >> those. >> >> Update operating-points-v2 bindings to support that. >> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > Looks mostly ok.. > >> --- >> Documentation/devicetree/bindings/power/opp.txt | 63 +++++++++++++++++++++++++ >> 1 file changed, 63 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt >> index 259bf00edf7d..72ccacaac9c9 100644 >> --- a/Documentation/devicetree/bindings/power/opp.txt >> +++ b/Documentation/devicetree/bindings/power/opp.txt >> @@ -45,10 +45,21 @@ Devices supporting OPPs must set their "operating-points-v2" property with >> phandle to a OPP table in their DT node. The OPP core will use this phandle to >> find the operating points for the device. >> >> +Devices may want to choose OPP tables at runtime and so can provide a list of >> +phandles here. But only *one* of them should be chosen at runtime. This must be >> +accompanied by a corresponding "operating-points-v2-names" property, to uniquely >> +identify the OPP tables. >> + >> If required, this can be extended for SoC vendor specfic bindings. Such bindings >> should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt >> and should have a compatible description like: "operating-points-v2-<vendor>". >> >> +Optional properties: >> +- operating-points-v2-names: Names of OPP tables (required if multiple OPP Let's drop v2. We know it only applies to v2. >> + tables are present), to uniquely identify them. The same list must be present >> + for all the CPUs which are sharing clock/voltage rails and hence the OPP >> + tables. >> + >> * OPP Table Node >> >> This describes the OPPs belonging to a device. This node can have following >> @@ -63,11 +74,16 @@ This describes the OPPs belonging to a device. This node can have following >> reference an OPP. >> >> Optional properties: >> +- opp-name: Name of the OPP table, to uniquely identify it if more than one OPP >> + table is supplied in "operating-points-v2" property of device. >> + > > But isn't this being removed? If it is removed, feel free to add > > Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Same question here. Acked-by: Rob Herring <robh@kernel.org> Rob
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>; + ... + }; + }; +};