[lkml]   [2013]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] cpufreq: cpufreq-cpu0: Use a sane boot frequency when booting with a mismatched bootloader configuration
On 11/18/2013 09:46 PM, Viresh Kumar wrote:
> On 19 November 2013 07:51, Shawn Guo <> wrote:
>> No, I did not say that. IMO, when cpufreq-cpu0 sees a mismatch, it has
>> no way to know or assume which one is correct and which is incorrect.
>> The best thing it can do is to fail out without changing anything about
>> running frequency and voltage.
> Not specifically on this patch, but this is what I feel about this issue:
> - As we are discussing on the other thread, there is scope of adding
> "unknown" field in tables so that people would know that they were
> running out of table freq at some point..

Consider something like userspace governor selection -> the device at
boot will probably remain in an unknown/"invalid" configuration till
the very first transition attempt. I am less worried about the stats
than not following what the hardware description is (as stated by
device tree/other forms).

I staunchly disagree that at a point of mismatch detection, we just
refuse to load up cpufreq governor -even though we know from device
tree/other alternative entries what the hardware behavior is supposed
to be. To refuse to loadup to a known configuration is considering the
"valid configuration" data provided to the driver is wrong - an
equivalent(considering the i2c example) is that if i2c driver sees bus
configured for 3.4MHz and was asked to use 100KHz, it just refuses to
load up!

> - This is a common problem for all drivers/platforms and not only
> cpufreq-cpu0, so the solution has to be generic and not driver
> specific.. So, atleast I don't want to get this patch in at any cost,
> unless there is a generic solution present..
> - There are non-dt drivers as well, and so freq table is present
> with the kernel and we can't support all frequencies that bootloader
> may end up with..
The above two are fair comments -> but that implies that policy->cur
population should no longer be the responsibility of cpufreq drivers
and be the responsibility of cpufreq core. are we stating we want to
move that to cpufreq core?

Nishanth Menon

 \ /
  Last update: 2013-11-19 15:21    [W:0.050 / U:0.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site