On Thu, 20 Jun 2013 10:41:41 +0530, Viresh Kumar wrote:
> On 19 June 2013 12:46, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote:
> > I would like to clarify the above issue.
> >
> > When I've discussed with Viresh previous version of this patch, we
> > have agreed, that "boost" sysfs attribute [*]:
> > /sys/devices/system/cpu/cpufreq/boost
> >
> > would be only visible when boost_supported flag is set at cpufreq
> > driver.
>
> Yes.
>
> > When acpi-cpufreq driver doesn't support boost, the attribute [*]
> > won't be exported at all. This contradicts the documentation and
> > legacy acpi-cpufreq behaviour.
>
> No they aren't contradictory. What the documentation meant was:
> acpi-cpufreq driver is used by lots of different x86 processors. Now
> all processors might not support boost inside x86 also. And for them
> we will keep 'boost' file readonly. This is done by following
> statement
Thanks for explanation.
>
> if (boot_cpu_has(X86_FEATURE_CPB) ||
> boot_cpu_has(X86_FEATURE_IDA)) { boost_supported = true;
> ....
> } else
> global_boost.attr.mode = 0444;
Grrr.... So simple and obvious solution [1].
>
> Documentation file doesn't talk about any other cpufreq driver, for
> them there is no concept like boost.
>
> You need to preserve this functionality.
Yes the idea [1], solves problem with legacy API.
>
> > Since I'm affraid to break API (with all its consequences :-) ), I
> > would like to be sure that this is OK, and thereof I'm allowed to
> > rewrite documentation accordingly.
> >
> > I simply need explicit permission from both maintainers :-).
>
> For me its okay to rewrite documentation.
I will extent documentation about the SW managed boost.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
