diff mbox

[v5,7/7] Documentation:cpufreq:boost: Update BOOST documentation

Message ID 1372927830-2949-8-git-send-email-l.majewski@samsung.com (mailing list archive)
State Changes Requested, archived
Headers show

Commit Message

Lukasz Majewski July 4, 2013, 8:50 a.m. UTC 
Since the support for software and hardware controlled boosting has been
added, the corresponding Documentation entry had been updated.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>

---
Changes for v5:
- New patch

 Documentation/cpu-freq/boost.txt |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

Comments

Viresh Kumar July 16, 2013, 10:01 a.m. UTC | #1 
On 4 July 2013 14:20, Lukasz Majewski <l.majewski@samsung.com> wrote:
> -Reading the file is always supported, even if the processor does not
> -support boosting. In this case the file will be read-only and always
> -reads as "0". Explicitly changing the permissions and writing to that
> -file anyway will return EINVAL.
> +The file is exported only when cpufreq driver supports boosting.
> +Explicitly changing the permissions and writing to that file anyway will
> +return EINVAL.

For acpi-cpufreq reading the file should be always supported. And this
must be mentioned in doc.
--
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
Lukasz Majewski July 16, 2013, 11:33 a.m. UTC | #2 
On Tue, 16 Jul 2013 15:31:43 +0530 Viresh Kumar viresh.kumar@linaro.org
wrote,
> On 4 July 2013 14:20, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > -Reading the file is always supported, even if the processor does
> > not -support boosting. In this case the file will be read-only and
> > always -reads as "0". Explicitly changing the permissions and
> > writing to that -file anyway will return EINVAL.
> > +The file is exported only when cpufreq driver supports boosting.
> > +Explicitly changing the permissions and writing to that file
> > anyway will +return EINVAL.
> 
> For acpi-cpufreq reading the file should be always supported. And this
> must be mentioned in doc.

As fair as I've understood our previous discussion (at [*]) we have
agreed about this. We only export boost attribute when it is supported
by cpufreq_driver. Rafael was very clear about exporting boost
attribute:

"Simple: Export it only when supported."

[*]: Re: [PATCH v4 2/7] cpufreq: Add boost frequency support in core
Viresh Kumar July 17, 2013, 5:22 a.m. UTC | #3 
On 16 July 2013 17:03, Lukasz Majewski <l.majewski@samsung.com> wrote:
> As fair as I've understood our previous discussion (at [*]) we have
> agreed about this. We only export boost attribute when it is supported
> by cpufreq_driver. Rafael was very clear about exporting boost
> attribute:
>
> "Simple: Export it only when supported."
>
> [*]: Re: [PATCH v4 2/7] cpufreq: Add boost frequency support in core

I don't want to search in the Archives but I am sure what we decided
earlier.

Rafael Said:
"Simple: Export it only when supported."

AND

"Don't change behavior of acpi-cpufreq driver"

If you see acpi-cpufreq driver carefully, it always creates "boost"
sysfs entry. If its not supported then it creates a read only entry.

So, please preserve that.
--
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
Lukasz Majewski July 17, 2013, 7:36 a.m. UTC | #4 
On Wed, 17 Jul 2013 10:52:18 +0530 Viresh Kumar viresh.kumar@linaro.org
wrote,
> On 16 July 2013 17:03, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > As fair as I've understood our previous discussion (at [*]) we have
> > agreed about this. We only export boost attribute when it is
> > supported by cpufreq_driver. Rafael was very clear about exporting
> > boost attribute:
> >
> > "Simple: Export it only when supported."
> >
> > [*]: Re: [PATCH v4 2/7] cpufreq: Add boost frequency support in core
> 
> I don't want to search in the Archives but I am sure what we decided
> earlier.

At v4 there was the old acpi-cpufreq.c behaviour preserved (with always
exporting boost - when not supported ro, when supported rw).

Due to Rafael and Dirk comments it has been rewritten at v5:

http://thread.gmane.org/gmane.linux.kernel/1511831/match=patch+v4+2+7+cpufreq+add+boost+frequency+support+core


> 
> Rafael Said:
> "Simple: Export it only when supported."
              [*]

> 
> AND
> 
> "Don't change behavior of acpi-cpufreq driver" 
              [**]
> 
> If you see acpi-cpufreq driver carefully, it always creates "boost"
> sysfs entry. If its not supported then it creates a read only entry.

For me those two statements [*] and [**] contradict:

At v5:
1. ARM - export "boost" only when supported (rw)
2. x86 - export boost only when x86 supports it (as rw). When x86
	 doesn't support HW boost - DO NOT export it at all.

At v4:
1. ARM - export "boost" only when supported (rw)
2. x86 - always export boost - no matter if supported or not. If not
	 supported, then export it as ro only.


> 
> So, please preserve that.
Viresh Kumar July 17, 2013, 7:59 a.m. UTC | #5 
On 17 July 2013 13:06, Lukasz Majewski <l.majewski@samsung.com> wrote:
> At v4 there was the old acpi-cpufreq.c behaviour preserved (with always
> exporting boost - when not supported ro, when supported rw).
>
> Due to Rafael and Dirk comments it has been rewritten at v5:
>
> http://thread.gmane.org/gmane.linux.kernel/1511831/match=patch+v4+2+7+cpufreq+add+boost+frequency+support+core
>
>
>>
>> Rafael Said:
>> "Simple: Export it only when supported."
>               [*]
>
>>
>> AND
>>
>> "Don't change behavior of acpi-cpufreq driver"
>               [**]
>>
>> If you see acpi-cpufreq driver carefully, it always creates "boost"
>> sysfs entry. If its not supported then it creates a read only entry.
>
> For me those two statements [*] and [**] contradict:
>
> At v5:
> 1. ARM - export "boost" only when supported (rw)
> 2. x86 - export boost only when x86 supports it (as rw). When x86
>          doesn't support HW boost - DO NOT export it at all.
>
> At v4:
> 1. ARM - export "boost" only when supported (rw)
> 2. x86 - always export boost - no matter if supported or not. If not
>          supported, then export it as ro only.

Okay, there is some confusion..

I have raised a query on your v4 mail.. lets see what people have to say.
--
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
Lukasz Majewski July 17, 2013, 8:13 a.m. UTC | #6 
On Wed, 17 Jul 2013 13:29:26 +0530 Viresh Kumar viresh.kumar@linaro.org
wrote,
> On 17 July 2013 13:06, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > At v4 there was the old acpi-cpufreq.c behaviour preserved (with
> > always exporting boost - when not supported ro, when supported rw).
> >
> > Due to Rafael and Dirk comments it has been rewritten at v5:
> >
> > http://thread.gmane.org/gmane.linux.kernel/1511831/match=patch+v4+2+7+cpufreq+add+boost+frequency+support+core
> >
> >
> >>
> >> Rafael Said:
> >> "Simple: Export it only when supported."
> >               [*]
> >
> >>
> >> AND
> >>
> >> "Don't change behavior of acpi-cpufreq driver"
> >               [**]
> >>
> >> If you see acpi-cpufreq driver carefully, it always creates "boost"
> >> sysfs entry. If its not supported then it creates a read only
> >> entry.
> >
> > For me those two statements [*] and [**] contradict:
> >
> > At v5:
> > 1. ARM - export "boost" only when supported (rw)
> > 2. x86 - export boost only when x86 supports it (as rw). When x86
> >          doesn't support HW boost - DO NOT export it at all.
> >
> > At v4:
> > 1. ARM - export "boost" only when supported (rw)
> > 2. x86 - always export boost - no matter if supported or not. If not
> >          supported, then export it as ro only.
> 
> Okay, there is some confusion..
> 
> I have raised a query on your v4 mail.. lets see what people have to
> say.

Ok.
diff mbox

Patch

diff --git a/Documentation/cpu-freq/boost.txt b/Documentation/cpu-freq/boost.txt
index 9b4edfc..dd62e13 100644
--- a/Documentation/cpu-freq/boost.txt
+++ b/Documentation/cpu-freq/boost.txt
@@ -17,8 +17,8 @@  Introduction
 Some CPUs support a functionality to raise the operating frequency of
 some cores in a multi-core package if certain conditions apply, mostly
 if the whole chip is not fully utilized and below it's intended thermal
-budget. This is done without operating system control by a combination
-of hardware and firmware.
+budget. The decision about boost disable/enable is made either at hardware
+(e.g. x86) or software (e.g ARM).
 On Intel CPUs this is called "Turbo Boost", AMD calls it "Turbo-Core",
 in technical documentation "Core performance boost". In Linux we use
 the term "boost" for convenience.
@@ -48,24 +48,24 @@  be desirable:
 User controlled switch
 ----------------------
 
-To allow the user to toggle the boosting functionality, the acpi-cpufreq
-driver exports a sysfs knob to disable it. There is a file:
+To allow the user to toggle the boosting functionality, the cpufreq core
+driver exports a sysfs knob to enable or disable it. There is a file:
 /sys/devices/system/cpu/cpufreq/boost
 which can either read "0" (boosting disabled) or "1" (boosting enabled).
-Reading the file is always supported, even if the processor does not
-support boosting. In this case the file will be read-only and always
-reads as "0". Explicitly changing the permissions and writing to that
-file anyway will return EINVAL.
+The file is exported only when cpufreq driver supports boosting.
+Explicitly changing the permissions and writing to that file anyway will
+return EINVAL.
 
 On supported CPUs one can write either a "0" or a "1" into this file.
 This will either disable the boost functionality on all cores in the
-whole system (0) or will allow the hardware to boost at will (1).
+whole system (0) or will allow the software or hardware to boost at will
+(1).
 
 Writing a "1" does not explicitly boost the system, but just allows the
-CPU (and the firmware) to boost at their discretion. Some implementations
-take external factors like the chip's temperature into account, so
-boosting once does not necessarily mean that it will occur every time
-even using the exact same software setup.
+CPU to boost at their discretion. Some implementations take external
+factors like the chip's temperature into account, so boosting once does
+not necessarily mean that it will occur every time even using the exact
+same software setup.
 
 
 AMD legacy cpb switch