Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 29 May 2013 12:39, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote:
> I also agree. Moreover, I think that there should be only one set of
> "boost" sysfs entries either it is supported by HW (Intel) or SW (ARM).

Yes, you need to change acpi-cpufreq driver too to use this common
infrastructure.

> I can think of two "basic" one:
> - max_turbo_freq (ro)

This is surely per policy as two separate clusters can have separate values.
And probably a better one would be scaling_boost_frequencies, that will
list all boost frequencies.

> - turbo_mode/boost (rw)

I am confused with these two names: boost and turbo.. Probably we
should use a single name everywhere. Because acpi-cpufreq is already
using boost, we might shift to that.

> - /sys/devices/system/cpu/cpufreq/boost

Obviously this one.

> On the other hand first option would be used with systems, where
> per-core (or core sets) frequency setting is possible (b.L, Snapdragon
> S4)

For now this feature would be enabled on all clusters and controlled
by cpu/cpufreq/boost.

> To sum up - the idea is as follow:
>
> 1. cpufreq_driver exports turbo_mode=1 when it supports overclocking
> (this support can be hardcoded or read from device tree)
>
> 2. Then proper entries are exported to sysfs.
>
> 3. User via sysfs (at [*]) can enable/disable the feature on demand

Bingo!!
--
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




[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux