Re: [PATCH] cpufreq: cpufreq-cpu0: Use a sane boot frequency whenbooting with a mismatched bootloader configuration
From: Viresh Kumar
Date: Tue Nov 19 2013 - 10:32:27 EST
On 19 November 2013 20:29, Nishanth Menon <nm@xxxxxx> wrote:
> Not completely true - reaching probe after boot in a few seconds may
> not mean that system will remain stable at that frequency for longer
> duration. From a silicon vendor perspective, I do know that we
> gaurentee the discrete frequencies in the data manual (and that gets
> populated in devicetree and hence in freq_table), but we will not
> guarentee any other frequency to be functional for any length of time.
> in short, if a actual product is manufactured and operational at a
> frequency we do not "officially support", there is a risk associated
> with that. just a boot on a few development systems do not ever
> guarentee productization capability.
Maybe for a long duration system isn't stable enough but should be
stable for few seconds Atleast?
As soon as ->init() of driver is called we will get a call to:
cpufreq_set_policy() from cpufreq_init_policy(). And we will execute
this for sure:
ret = __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
On this call if the current freq is lesser or greater than policy limits,
then we will fix it straight away.. Otherwise whichever the governor
is, we will change the freq to any from freq-table very soon..
So, we need a real example of unstable system which really
requires your patch. Otherwise I feel that we will not face any problems
at all..
> So, to summarize: what is our overall strategy here? to move to a
> frequency matched in freq_table OR just giveup? I can try and respin
> accordingly.
I want cpufreq-stats to be fixed with something else, might be something
similar to the patch I have sent..
But this stuff can be left as is..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/