[PATCH v3 2/6] drivers/cpufreq: implement init_cpu_capacity_default()

Dietmar Eggemann dietmar.eggemann at arm.com
Tue Feb 9 07:54:50 PST 2016


On 05/02/16 09:30, Juri Lelli wrote:
> On 04/02/16 16:46, Vincent Guittot wrote:
>> On 4 February 2016 at 16:44, Vincent Guittot <vincent.guittot at linaro.org> wrote:
>>> On 4 February 2016 at 15:13, Juri Lelli <juri.lelli at arm.com> wrote:
>>>> On 04/02/16 13:35, Vincent Guittot wrote:
>>>>> On 4 February 2016 at 13:16, Juri Lelli <juri.lelli at arm.com> wrote:
>>>>>> Hi Vincent,
>>>>>>
>>>>>> On 04/02/16 13:03, Vincent Guittot wrote:
>>>>>>> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
>>>>>>>> On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
>>>>>>>>> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:

[...]

>>>
>>> AFAICT, They don't have a dedicated cpufreq driver.
>>>
>>> More generally speaking, it can take time before having
>>
>> email sent before the ne d of the sentence ...
>>
>> More generally speaking, it can take time before having a cpufreq
>> driver whereas we want to run and test scheduler behavior of these
>> heterogenous platform
>>
> 
> I'm not familiar with this platform, but from what you are saying and
> what I could find online, it looks like full Linux support is not
> finished yet. Can we consider that as still in development? And if we
> can do that, maybe is fair enough that we use the sysfs interface to
> play with that platform until support is complete.
> 
> Do others have any opinion on this point?

IMHO, the solution should work for all of heterogeneous systems, (a) w/
cpufreq and driver, (b) w/ cpufreq and no driver loaded (yet) or (c) w/o
cpufreq.

That means that you can't put the benchmarking only into
cpufreq_register_driver() and rely on cpufreq policy topology.

Maybe you could do this for (b) and (c) inside an initcall and use
topology_core_cpumask() to figure out which cpu to profile?

This would then happen w/ the cpu frequency set by the fw.

But this then has to be synchronized somehow with the benchmarking
approach in cpufreq_register_driver().

[...]



More information about the linux-arm-kernel mailing list