When someone added the dbs_cpufreq_notifier section to the governor the code ended up causing the frequency to only fall. This is because requested_freq is tinkered with and that should only modified if it has an invlaid value due to changes in the available frequency ranges This should fix #10055. Signed-off-by: Alexander Clouter <alex@xxxxxxxxxxxxx> --- drivers/cpufreq/cpufreq_conservative.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c index a18cfbf..a16a5b8 100644 --- a/drivers/cpufreq/cpufreq_conservative.c +++ b/drivers/cpufreq/cpufreq_conservative.c @@ -137,10 +137,21 @@ dbs_cpufreq_notifier(struct notifier_block *nb, unsigned long val, struct cpu_dbs_info_s *this_dbs_info = &per_cpu(cpu_dbs_info, freq->cpu); + struct cpufreq_policy *policy; + if (!this_dbs_info->enable) return 0; - this_dbs_info->requested_freq = freq->new; + policy = this_dbs_info->cur_policy; + + /* + * we only care if our internally tracked freq moves outside + * the 'valid' ranges of freqency available to us otherwise + * we do not change it + */ + if (this_dbs_info->requested_freq > policy->max + || this_dbs_info->requested_freq < policy->min) + this_dbs_info->requested_freq = freq->new; return 0; } -- 1.5.6.5 -- 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
