On 07/02/14 16:43, Nishanth Menon wrote: > On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@xxxxxxx> wrote: >> On 07/02/14 16:15, Sudeep Holla wrote: >>> On 07/02/14 15:19, Thomas Abraham wrote: >>>> From: Thomas Abraham <thomas.ab@xxxxxxxxxxx> >>>> >>>> Add a new optional boost-frequency binding for specifying the frequencies >>>> usable in boost mode. >>>> >>>> Cc: Nishanth Menon <nm@xxxxxx> >>>> Cc: Lukasz Majewski <l.majewski@xxxxxxxxxxx> >>>> Cc: Rob Herring <robh+dt@xxxxxxxxxx> >>>> Cc: Pawel Moll <pawel.moll@xxxxxxx> >>>> Cc: Mark Rutland <mark.rutland@xxxxxxx> >>>> Cc: Ian Campbell <ijc+devicetree@xxxxxxxxxxxxxx> >>>> Cc: Kumar Gala <galak@xxxxxxxxxxxxxx> >>>> Signed-off-by: Thomas Abraham <thomas.ab@xxxxxxxxxxx> >>>> --- >>>> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++++++++++ >>>> 1 file changed, 11 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >>>> new file mode 100644 >>>> index 0000000..d925e38 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt >>>> @@ -0,0 +1,11 @@ >>>> +* Device tree binding for CPU boost frequency (aka over-clocking) >>>> + >>>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as >>>> +overclocking) in which the CPU can operate in frequencies beyond the normal >>>> +operating conditions. >>>> + >>>> +Optional Properties: >>>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode. >>>> + This list should be a subset of frequencies listed in "operating-points" >>>> + property. Refer to Documentation/devicetree/bindings/power/opp.txt for >>>> + details about "operating-points" property. >>>> >>> >>> Won't single entry for boost frequency suffice which would be the starting >>> frequency in the boost range. IOW will there be OPP list with frequencies: >>> A > B > C > D, but only B and C are boost frequency. That seems little odd, >>> unless it's some configuration chosen purely on software basis rather than >>> hardware. For me B marks the beginning of over-clocking. >>> >> Ah, I meant A < B < C < D in the above example. > > Should'nt we let the SoC dts define that - traditionally, yes, but > consider the following: > A, B, C uses clk_parent X which describes B, C as overclocked. > and say D uses clk_parent Y which is not "over clocked", then you have > the scenario that on the first look seems counter-intutive. > Yes I thought of exactly similar clock setup, but was not convinced that it should be part of OPP. In that case it looks like we are trying to represent clock internals through some OPP bindings. Yes I think its counter-intuitive as it's visible to the userspace(list of frequencies and the boost parameters are exposed through sysfs) Regards, Sudeep -- 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
