On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <[email protected]> wrote: > On 07/02/14 16:15, Sudeep Holla wrote: >> On 07/02/14 15:19, Thomas Abraham wrote: >>> From: Thomas Abraham <[email protected]> >>> >>> Add a new optional boost-frequency binding for specifying the frequencies >>> usable in boost mode. >>> >>> Cc: Nishanth Menon <[email protected]> >>> Cc: Lukasz Majewski <[email protected]> >>> Cc: Rob Herring <[email protected]> >>> Cc: Pawel Moll <[email protected]> >>> Cc: Mark Rutland <[email protected]> >>> Cc: Ian Campbell <[email protected]> >>> Cc: Kumar Gala <[email protected]> >>> Signed-off-by: Thomas Abraham <[email protected]> >>> --- >>> 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.
Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
