| Message ID | 1391786342-11812-3-git-send-email-thomas.ab@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote: > From: Thomas Abraham <thomas.ab@samsung.com> > > Add a new optional boost-frequency binding for specifying the frequencies > usable in boost mode. > > Cc: Nishanth Menon <nm@ti.com> > Cc: Lukasz Majewski <l.majewski@samsung.com> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Pawel Moll <pawel.moll@arm.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> > Cc: Kumar Gala <galak@codeaurora.org> > Signed-off-by: Thomas Abraham <thomas.ab@samsung.com> > --- > 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. boost-frequencies? > + 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. > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 7, 2014 at 8:57 PM, Nishanth Menon <nm@ti.com> wrote: > On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote: >> From: Thomas Abraham <thomas.ab@samsung.com> >> >> Add a new optional boost-frequency binding for specifying the frequencies >> usable in boost mode. >> >> Cc: Nishanth Menon <nm@ti.com> >> Cc: Lukasz Majewski <l.majewski@samsung.com> >> Cc: Rob Herring <robh+dt@kernel.org> >> Cc: Pawel Moll <pawel.moll@arm.com> >> Cc: Mark Rutland <mark.rutland@arm.com> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> >> Cc: Kumar Gala <galak@codeaurora.org> >> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com> >> --- >> 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. > > boost-frequencies? Okay, I will change it. Thanks, Thomas. > >> + 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. >> -- >> 1.7.10.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pm" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/02/14 15:19, Thomas Abraham wrote: > From: Thomas Abraham <thomas.ab@samsung.com> > > Add a new optional boost-frequency binding for specifying the frequencies > usable in boost mode. > > Cc: Nishanth Menon <nm@ti.com> > Cc: Lukasz Majewski <l.majewski@samsung.com> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Pawel Moll <pawel.moll@arm.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> > Cc: Kumar Gala <galak@codeaurora.org> > Signed-off-by: Thomas Abraham <thomas.ab@samsung.com> > --- > 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. IWO 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. Regards, Sudeep
On 07/02/14 16:15, Sudeep Holla wrote: > On 07/02/14 15:19, Thomas Abraham wrote: >> From: Thomas Abraham <thomas.ab@samsung.com> >> >> Add a new optional boost-frequency binding for specifying the frequencies >> usable in boost mode. >> >> Cc: Nishanth Menon <nm@ti.com> >> Cc: Lukasz Majewski <l.majewski@samsung.com> >> Cc: Rob Herring <robh+dt@kernel.org> >> Cc: Pawel Moll <pawel.moll@arm.com> >> Cc: Mark Rutland <mark.rutland@arm.com> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> >> Cc: Kumar Gala <galak@codeaurora.org> >> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com> >> --- >> 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. Regards, Sudeep
On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: > On 07/02/14 16:15, Sudeep Holla wrote: >> On 07/02/14 15:19, Thomas Abraham wrote: >>> From: Thomas Abraham <thomas.ab@samsung.com> >>> >>> Add a new optional boost-frequency binding for specifying the frequencies >>> usable in boost mode. >>> >>> Cc: Nishanth Menon <nm@ti.com> >>> Cc: Lukasz Majewski <l.majewski@samsung.com> >>> Cc: Rob Herring <robh+dt@kernel.org> >>> Cc: Pawel Moll <pawel.moll@arm.com> >>> Cc: Mark Rutland <mark.rutland@arm.com> >>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> >>> Cc: Kumar Gala <galak@codeaurora.org> >>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com> >>> --- >>> 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
On 07/02/14 16:43, Nishanth Menon wrote: > On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: >> On 07/02/14 16:15, Sudeep Holla wrote: >>> On 07/02/14 15:19, Thomas Abraham wrote: >>>> From: Thomas Abraham <thomas.ab@samsung.com> >>>> >>>> Add a new optional boost-frequency binding for specifying the frequencies >>>> usable in boost mode. >>>> >>>> Cc: Nishanth Menon <nm@ti.com> >>>> Cc: Lukasz Majewski <l.majewski@samsung.com> >>>> Cc: Rob Herring <robh+dt@kernel.org> >>>> Cc: Pawel Moll <pawel.moll@arm.com> >>>> Cc: Mark Rutland <mark.rutland@arm.com> >>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> >>>> Cc: Kumar Gala <galak@codeaurora.org> >>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com> >>>> --- >>>> 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
On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: > > 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. And this series (rightly) does not make it an OPP behavior. instead all it does is to list the boost-frequencies and mark those in cpufreq table. the description is left to the dts and implementation to the clock drivers involved. > Yes I think its counter-intuitive as it's visible to the userspace(list of > frequencies and the boost parameters are exposed through sysfs) That will be a different problem -> as currently every single frequency in the cpufreq list has ability to be marked as boost frequency - if userspace does not maintain that, then, IMHO, fix the userspace :D Regards, Nishanth Menon
On Fri, Feb 7, 2014 at 11:37 AM, Nishanth Menon <nm@ti.com> wrote: > On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: >> >> 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. > > And this series (rightly) does not make it an OPP behavior. instead > all it does is to list the boost-frequencies and mark those in cpufreq > table. the description is left to the dts and implementation to the > clock drivers involved. One more thing, before I forget -> currently dev_pm_opp_[init|free]_cpufreq_table is in drivers/base/power/opp.c -> this probably should go away to drivers/cpufreq to keep opp.c independent of frameworks using it. i dont see any code that is introduced in the mentioned functions as being OPP behavior specific, instead, I consider them as cpufreq+opp behaviors, which this change fits into. Regards, Nishanth Menon
On 07/02/14 17:37, Nishanth Menon wrote: > On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: [...] >> Yes I think its counter-intuitive as it's visible to the userspace(list of >> frequencies and the boost parameters are exposed through sysfs) > > That will be a different problem -> as currently every single > frequency in the cpufreq list has ability to be marked as boost > frequency - if userspace does not maintain that, then, IMHO, fix the > userspace :D > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives the list of frequencies based on the state of the boost feature at anytime. Intuitively the list without boost shouldn't have any frequency above the range when it's enabled :), that's what I was referring to. So I am not talking about any issue with user-space maintenance. Regards, Sudeep
On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: > On 07/02/14 17:37, Nishanth Menon wrote: >> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: > > [...] > >>> Yes I think its counter-intuitive as it's visible to the userspace(list of >>> frequencies and the boost parameters are exposed through sysfs) >> >> That will be a different problem -> as currently every single >> frequency in the cpufreq list has ability to be marked as boost >> frequency - if userspace does not maintain that, then, IMHO, fix the >> userspace :D >> > > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives > the list of frequencies based on the state of the boost feature at anytime. > > Intuitively the list without boost shouldn't have any frequency above the range > when it's enabled :), that's what I was referring to. So I am not talking about > any issue with user-space maintenance. Fair enough - but i still think it has nothing to do with dt binding itself -> and i think the discussion we've had should be good for the binding provided in this patch.. I hope.. if documentation needs a bit of better explanation to prevent a repeat of the same discussion at a later point of time, now might be a good time to add it in. Regards, Nishanth Menon
On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: > On 07/02/14 17:37, Nishanth Menon wrote: >> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: > > [...] > >>> Yes I think its counter-intuitive as it's visible to the userspace(list of >>> frequencies and the boost parameters are exposed through sysfs) >> >> That will be a different problem -> as currently every single >> frequency in the cpufreq list has ability to be marked as boost >> frequency - if userspace does not maintain that, then, IMHO, fix the >> userspace :D >> > > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives > the list of frequencies based on the state of the boost feature at anytime. The list of frequencies in /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies does not change based in the state of the boost feature (enabled or disabled). But the scaling_max_frequency and scaling_min_frequency are updated based on the set of available + boost frequencies available. > > Intuitively the list without boost shouldn't have any frequency above the range > when it's enabled :), that's what I was referring to. So I am not talking about > any issue with user-space maintenance. > > Regards, > Sudeep >
On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote: > On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: >> On 07/02/14 17:37, Nishanth Menon wrote: >>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: >> >> [...] >> >>>> Yes I think its counter-intuitive as it's visible to the userspace(list of >>>> frequencies and the boost parameters are exposed through sysfs) >>> >>> That will be a different problem -> as currently every single >>> frequency in the cpufreq list has ability to be marked as boost >>> frequency - if userspace does not maintain that, then, IMHO, fix the >>> userspace :D >>> >> >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives >> the list of frequencies based on the state of the boost feature at anytime. >> >> Intuitively the list without boost shouldn't have any frequency above the range >> when it's enabled :), that's what I was referring to. So I am not talking about >> any issue with user-space maintenance. > Fair enough - but i still think it has nothing to do with dt binding > itself -> and i think the discussion we've had should be good for the > binding provided in this patch.. I hope.. if documentation needs a bit > of better explanation to prevent a repeat of the same discussion at a > later point of time, now might be a good time to add it in. The term boost and over-clocking have been described in the bindings document as being the same. Since the term over-clocking refers to running a CPU beyond normal operating frequencies, I tend to agree with Sudeep that it is not intuitive if a normal operating frequency is greater than a boost mode frequency. Otherwise, when userspace does "echo 1 > /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I think the original intent of boost mode patches was to allow CPU to operate at frequencies greater than the normal operating frequencies. Lukasz, how would you want this to be handled? Thanks, Thomas. > > Regards, > Nishanth Menon
Hi Thomas, Sudeep, > On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> > wrote: > > On 07/02/14 17:37, Nishanth Menon wrote: > >> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla > >> <Sudeep.Holla@arm.com> wrote: > > > > [...] > > > >>> Yes I think its counter-intuitive as it's visible to the > >>> userspace(list of frequencies and the boost parameters are > >>> exposed through sysfs) > >> > >> That will be a different problem -> as currently every single > >> frequency in the cpufreq list has ability to be marked as boost > >> frequency - if userspace does not maintain that, then, IMHO, fix > >> the userspace :D > >> > > > > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies > > gives the list of frequencies based on the state of the boost > > feature at anytime. > > The list of frequencies in > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies > does not change based in the state of the boost feature (enabled or > disabled). But the scaling_max_frequency and scaling_min_frequency are > updated based on the set of available + boost frequencies available. With boost intended behavior is as follow: /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies [1] shows the non boost frequencies no matter if boost is enabled or not. Those are the "normal" frequencies. When boost is supported (by enabling the CONFIG_CPU_FREQ_BOOST_SW) extra sysfs attribute shows up: /sys/devices/system/cpu/cpu0/cpufreq/scaling_boost_frequencies [2] in which are listed only the boost frequencies. If the dts doesn't provide any values or as it is now no CPUFREQ_BOOST_FREQ flag is specified (at exynos4x12-cpufreq.c), then this list is empty. When boost is disabled the max freq (cpuinfo_max_freq) is in the range listed at [1]. When boost is enabled this value is the sum of freqs represented at [1] and [2]. By adding an extra attribute [2] we: 1. Indicate that boost is supported 2. List provided BOOST frequencies 3. Separate boost and non boost freqs > > > > > Intuitively the list without boost shouldn't have any frequency > > above the range when it's enabled :), that's what I was referring > > to. So I am not talking about any issue with user-space maintenance. > > > > Regards, > > Sudeep > >
Hi Thomas, Sudeep, > On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote: > > On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla > > <Sudeep.Holla@arm.com> wrote: > >> On 07/02/14 17:37, Nishanth Menon wrote: > >>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla > >>> <Sudeep.Holla@arm.com> wrote: > >> > >> [...] > >> > >>>> Yes I think its counter-intuitive as it's visible to the > >>>> userspace(list of frequencies and the boost parameters are > >>>> exposed through sysfs) > >>> > >>> That will be a different problem -> as currently every single > >>> frequency in the cpufreq list has ability to be marked as boost > >>> frequency - if userspace does not maintain that, then, IMHO, fix > >>> the userspace :D > >>> > >> > >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies > >> gives the list of frequencies based on the state of the boost > >> feature at anytime. > >> > >> Intuitively the list without boost shouldn't have any frequency > >> above the range when it's enabled :), that's what I was referring > >> to. So I am not talking about any issue with user-space > >> maintenance. > > Fair enough - but i still think it has nothing to do with dt binding > > itself -> and i think the discussion we've had should be good for > > the binding provided in this patch.. I hope.. if documentation > > needs a bit of better explanation to prevent a repeat of the same > > discussion at a later point of time, now might be a good time to > > add it in. > > The term boost and over-clocking have been described in the bindings > document as being the same. Since the term over-clocking refers to > running a CPU beyond normal operating frequencies, I tend to agree > with Sudeep that it is not intuitive if a normal operating frequency > is greater than a boost mode frequency. > > Otherwise, when userspace does "echo 1 > > /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I > think the original intent of boost mode patches was to allow CPU to > operate at frequencies greater than the normal operating frequencies. > > Lukasz, how would you want this to be handled? Please consider an example: normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000 [1] boost-freqs: 1700000, 1600000, 1500000. [2] All those freqs shall be represented as OPPs freq and voltage tuple. Best would be to specify all the boost-freqs as: boost-freqs = <1700000 1600000 1500000> to be prepared for future quirks or problems (or special cases which might show up latter). If anybody can foresee any potential threads - like platform on which boost freqs are 1700000 and 1500000, but not 1600000, then please share this information. However, I think that it would be also acceptable to specify only: boost-freq = <1500000> and mark all freqs greater or equal to it as CPUFREQ_BOOST_FREQ. If there aren't any potential problems, then I think the second option would be a good solution (we would have only one BOOST attribute stored at CPUs DTS node). > > Thanks, > Thomas. > > > > > Regards, > > Nishanth Menon > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 08/02/14 06:47, Thomas Abraham wrote: > On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: >> On 07/02/14 17:37, Nishanth Menon wrote: >>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote: >> >> [...] >> >>>> Yes I think its counter-intuitive as it's visible to the userspace(list of >>>> frequencies and the boost parameters are exposed through sysfs) >>> >>> That will be a different problem -> as currently every single >>> frequency in the cpufreq list has ability to be marked as boost >>> frequency - if userspace does not maintain that, then, IMHO, fix the >>> userspace :D >>> >> >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives >> the list of frequencies based on the state of the boost feature at anytime. > > The list of frequencies in > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies > does not change based in the state of the boost feature (enabled or > disabled). But the scaling_max_frequency and scaling_min_frequency are > updated based on the set of available + boost frequencies available. > Ah ok, sorry just glanced the code and misunderstood it. It make sense to update only max_frequency. Regards, Sudeep
On 10/02/14 07:38, Lukasz Majewski wrote: > Hi Thomas, Sudeep, > >> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> >> wrote: >>> On 07/02/14 17:37, Nishanth Menon wrote: >>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla >>>> <Sudeep.Holla@arm.com> wrote: >>> >>> [...] >>> >>>>> Yes I think its counter-intuitive as it's visible to the >>>>> userspace(list of frequencies and the boost parameters are >>>>> exposed through sysfs) >>>> >>>> That will be a different problem -> as currently every single >>>> frequency in the cpufreq list has ability to be marked as boost >>>> frequency - if userspace does not maintain that, then, IMHO, fix >>>> the userspace :D >>>> >>> >>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies >>> gives the list of frequencies based on the state of the boost >>> feature at anytime. >> >> The list of frequencies in >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies >> does not change based in the state of the boost feature (enabled or >> disabled). But the scaling_max_frequency and scaling_min_frequency are >> updated based on the set of available + boost frequencies available. > > With boost intended behavior is as follow: > > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies [1] > > shows the non boost frequencies no matter if boost is enabled or not. > Those are the "normal" frequencies. > > When boost is supported (by enabling the CONFIG_CPU_FREQ_BOOST_SW) > extra sysfs attribute shows up: > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_boost_frequencies [2] > in which are listed only the boost frequencies. > Correct, sorry I misunderstood this to dynamic change in scaling_available_frequencies based on state of boot. Regards, Sudeep
On 10/02/14 07:53, Lukasz Majewski wrote: > Hi Thomas, Sudeep, > >> On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote: >>> On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla >>> <Sudeep.Holla@arm.com> wrote: >>>> On 07/02/14 17:37, Nishanth Menon wrote: >>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla >>>>> <Sudeep.Holla@arm.com> wrote: >>>> >>>> [...] >>>> >>>>>> Yes I think its counter-intuitive as it's visible to the >>>>>> userspace(list of frequencies and the boost parameters are >>>>>> exposed through sysfs) >>>>> >>>>> That will be a different problem -> as currently every single >>>>> frequency in the cpufreq list has ability to be marked as boost >>>>> frequency - if userspace does not maintain that, then, IMHO, fix >>>>> the userspace :D >>>>> >>>> >>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies >>>> gives the list of frequencies based on the state of the boost >>>> feature at anytime. >>>> >>>> Intuitively the list without boost shouldn't have any frequency >>>> above the range when it's enabled :), that's what I was referring >>>> to. So I am not talking about any issue with user-space >>>> maintenance. >>> Fair enough - but i still think it has nothing to do with dt binding >>> itself -> and i think the discussion we've had should be good for >>> the binding provided in this patch.. I hope.. if documentation >>> needs a bit of better explanation to prevent a repeat of the same >>> discussion at a later point of time, now might be a good time to >>> add it in. >> Nishanth, though I am not convinced that it should be list, since you have a valid point that this should not prevent in having this feature, I am fine with the list. >> The term boost and over-clocking have been described in the bindings >> document as being the same. Since the term over-clocking refers to >> running a CPU beyond normal operating frequencies, I tend to agree >> with Sudeep that it is not intuitive if a normal operating frequency >> is greater than a boost mode frequency. >> >> Otherwise, when userspace does "echo 1 > >> /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I >> think the original intent of boost mode patches was to allow CPU to >> operate at frequencies greater than the normal operating frequencies. >> >> Lukasz, how would you want this to be handled? > > Please consider an example: > > normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000 > [1] > boost-freqs: 1700000, 1600000, 1500000. [2] > > All those freqs shall be represented as OPPs freq and voltage tuple. > > Best would be to specify all the boost-freqs as: > boost-freqs = <1700000 1600000 1500000> to be prepared for future > quirks or problems (or special cases which might show up latter). > If anybody can foresee any potential threads - like platform on which > boost freqs are 1700000 and 1500000, but not 1600000, then please share > this information. > If that's the case then why should it be included in the list of OPPs. I know Nishanth had a valid point in other thread previously(like including SoC.dtsi having OPPs in platform files), but that's different problem. > However, I think that it would be also acceptable to specify only: > boost-freq = <1500000> and mark all freqs greater or equal to it as > CPUFREQ_BOOST_FREQ. > > If there aren't any potential problems, then I think the second option > would be a good solution (we would have only one BOOST attribute stored > at CPUs DTS node). > Yes I prefer this to keep it simple and as per the definition of overclocking or turbo boost in hardware terms if possible. Just another thought, not sure how much this is true for real platforms, sharing it anyway. IIUC these boost frequencies have certain constraints like thermal and can't be sustained all the processors for long time. So does it make sense to specify normal max frequency instead of boost-frequency which by definition would be: "The maximum frequency that all processors are can sustain simultaneously without any thermal constraints". Ignore this if this is not the definition of boost on real platforms. Regards, Sudeep
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.