[CPUFREQ] add support for cpufreq governors.
More bits from Dominik. Most cpufreq drivers (in fact, all except one, longrun) or even most cpu frequency scaling algorithms only offer the CPU to be set to one frequency. In order to offer dynamic frequency scaling, the cpufreq core must be able to tell these drivers of a "target frequency". So these specific drivers will be transformed to offer a "->target" call instead of the existing "->setpolicy" call. For "longrun", all stays the same, though. How to decide what frequency within the CPUfreq policy should be used? That's done using "cpufreq governors". Two are already in this patch -- they're the already existing "powersave" and "performance" which set the frequency statically to the lowest or highest frequency, respectively. At least two more such governors will be ready for addition in the near future, but likely many more as there are various different theories and models about dynamic frequency scaling around. Using such a generic interface as cpufreq offers to scaling governors, these can be tested extensively, and the best one can be selected for each specific use. Basically, it's the following flow graph: CPU can be set to switch independetly | CPU can only be set within specific "limits" | to specific frequencies "CPUfreq policy" consists of frequency limits (policy->{min,max}) and CPUfreq governor to be used / \ / \ / the cpufreq governor decides / (dynamically or statically) / what target_freq to set within / the limits of policy->{min,max} / \ / \ Using the ->setpolicy call, Using the ->target call, the limits and the the frequency closest "policy" is set. to target_freq is set. It is assured that it is within policy->{min,max}
Showing
This diff is collapsed.
Please register or sign in to comment