On Tue, 28 Jul 2015, Viresh Kumar wrote: > On 27-07-15, 16:20, Lee Jones wrote: > > Cc: devicetree@xxxxxxxxxxxxxxx > > Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx> > > --- > > > > Changelog: > > - Using OPP-v2 > > - Moved (and linked) a bunch of documentation to ../power/ > > > > .../devicetree/bindings/cpufreq/cpufreq-st.txt | 40 ++++++++++++++++++++++ > > 1 file changed, 40 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt > > > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt > > new file mode 100644 > > index 0000000..79add9d > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt > > @@ -0,0 +1,40 @@ > > +Binding for ST's CPUFreq driver > > +=============================== > > + > > +Frequency Scaling only > > +---------------------- > > + > > +Located in CPU's node: > > + > > +- operating-points : [See: ../power/opp.txt] > > + > > +Example [safe] > > +-------------- > > + > > +cpus { > > + cpu@0 { > > + /* kHz uV */ > > + operating-points = <1500000 0 > > + 1200000 0 > > + 800000 0 > > + 500000 0>; > > + }; > > +}; > > + > > +Dynamic Voltage and Frequency Scaling (DVFS) > > +-------------------------------------------- > > + > > +Located in CPU's node: > > + > > +- operating-points-v2-sti : [See ../power/opp-st.txt] > > + > > +Example [unsafe] > > +---------------- > > + > > +cpus { > > + cpu@0 { > > + operating-points-v2 = <[OPP list phandle]>; > > + }; > > +}; > > + > > +For an example of an OPP list, see ../power/opp-st.txt. > > I don't think you need this file/patch at all.. It is almost blank and > doesn't define a binding. And so there is no need to specify this at > all. Just an OPP binding file is enough. I have two issues with that. Firstly, although the driver uses the OPP API (it also uses the Regulator and Clock API too), it is fundamentally a CPUFreq driver, so I think it should have a CPUFreq DT entry. Secondly, if someone doesn't know the history of the ST CPUFreq set, they will look here for an accompanying document. I personally wouldn't think to look in power/*opp* for a CPUFreq binding. Perhaps, as all of the CPUFreq drivers use the OPP API, everything should be moved to drivers/base/power or drivers/power? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html