>> >> + if (target_freq <= >> >(ioread32(&pcch_hdr->minimum_frequency) * 1000)) { >> >> + target_freq = >> >ioread32(&pcch_hdr->minimum_frequency) * 1000; >> >> + dprintk("target: target_freq for cpu %d was >> >below limit, " >> >> + "converted it to %d\n", cpu, target_freq); >> >> + } >> > >> >why not do this in the _verify() step? Does >pcch_hdr->minimum_frequency >> >even change "on the fly"? >> >> pcch_hdr->minimum_frequency does not change "on the fly". >Also, there is no >> need for those IO accesses: > >target_freq cannot be below policy->min or above policy->max. >If it were, >the whole cpufreq subsystem is broken. So there's no need for >these checks, >AFAICS. > I think the "ondemand" governor can ask for a target frequency that is below policy->min. Let's say that at a given snapshot, the frequency of a CPU is policy->cur. At the next sampling, if the "load" on the CPU drops to a level that satisifies the equation below, then freq_next requested by "ondemand" will be below policy->min: load < (threshold - differential) * policy->min / policy->cur A patch such as below may be needed to sanitize the target frequency requested by "ondemand". The "conservative" governor already has this check: # diff -bur ./drivers/cpufreq/cpufreq_ondemand.c.orig ./drivers/cpufreq/cpufreq_ondemand.c --- ./drivers/cpufreq/cpufreq_ondemand.c.orig 2009-12-11 15:06:02.000000000 -0600 +++ ./drivers/cpufreq/cpufreq_ondemand.c 2009-12-15 20:27:57.000000000 -0600 @@ -554,6 +554,9 @@ (dbs_tuners_ins.up_threshold - dbs_tuners_ins.down_differential); + if (freq_next < policy->min) + freq_next = policy->min; + if (!dbs_tuners_ins.powersave_bias) { __cpufreq_driver_target(policy, freq_next, CPUFREQ_RELATION_L); - naga - -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html