Re: cpufreq: Unable to set cpufreq to maximum

[Stefan Wahren <stefan.wahren@i2se.com>]

Am 06.10.2014 um 06:21 schrieb Viresh Kumar:
> On 2 October 2014 20:52, Lucas Stach <l.stach@pengutronix.de> wrote:
>> It's harmless in your case. But to get rid of it you might try the
>> attached patch which may be an acceptable solution.
>>
>> ------------------------------>8-----------------------------------
>> From db9e708edf6451b619ee73f68c3fcde2eccd7b0c Mon Sep 17 00:00:00 2001
>> From: Lucas Stach <l.stach@pengutronix.de>
>> Date: Thu, 2 Oct 2014 17:20:09 +0200
>> Subject: [PATCH] cpufreq: generic: try preserve some accuracy while
>> converting
>>  from Hz to kHz
>>
>> ---
>>  drivers/cpufreq/cpufreq.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index d9fdeddcef96..459830c6576f 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -187,7 +187,7 @@ unsigned int cpufreq_generic_get(unsigned int cpu)
>>                 return 0;
>>         }
>>
>> -       return clk_get_rate(policy->clk) / 1000;
>> +       return DIV_ROUND_CLOSEST(clk_get_rate(policy->clk), 1000);
>>  }
>>  EXPORT_SYMBOL_GPL(cpufreq_generic_get);
> Absolutely NOT..
>
> This can't be an acceptable solution to the problem you have in your DT.
> This routine is used for getting the current frequency of a CPU and we
> can't play with that..

I thought about it and agree with you.

> The problem that Stefan is getting is: The boot loader has programmed
> cpu to a frequency which isn't present in your DT table. And so kernel
> tries to adjust CPU frequency to one of the listed frequencies.

Here comes the real problem, i'm not able to specify the exact frequency
of the cpu. The clock has a value in Hz, but in the DT we have kHz. So
there are always rounding issues. The question is how to handle it.

> Solutions:
> - Add another entry to your DT table to reflect the currently programmed
> frequency.
> - Just ignore the error, as that is just for information.

Ignoring errors isn't a solution. I have another idea. I've looked a
little bit at the code in the cpufreq-(cpu0/dt). Usually the frequencies
are rounded down, but in cpu0_set_target() with
dev_pm_opp_find_freq_ceil(cpu_dev, &freq_Hz) they are rounded up. From
my point of view that's wrong.

I fixed the problem by decreasing frequency in DT and replacing
dev_pm_opp_find_freq_ceil() with dev_pm_opp_find_freq_floor() in
cpufreq-cpu0.c . Unfortunatelly this will break all other DTS files with
roundings in OPPs.

Stefan