On Tue, Oct 07, 2014 at 12:48:44PM +0100, Mark Brown wrote:
> Hi,
>
> The power management team at Linaro has had a look at the cpufreq
> updates since the v3.10 LTS and identified a few patches that look
> like they should be in there. The most recent of these is from v3.12 so
> they won't apply to any of the more recent stable kernels.
CCing in the actual stable list rather than the nonexistant linux-stable.
> - 59a6342203a7a cpufreq: Fix governor start/stop race condition
>
> This looks like a straight race condition fix.
>
> - 19c763031acb8 cpufreq: serialize calls to __cpufreq_governor()
>
> The commit message here outlines a scenario where this change fixes a
> crash which seems like stable material to me. There is a context
> change that needs a fixup but it's fairly trivial:
>
> diff --cc drivers/cpufreq/cpufreq.c
> index c34d4423f298,7e6baa58a7f2..000000000000
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@@ -1586,8 -1692,10 +1586,9 @@@ static int __cpufreq_governor(struct cp
> policy->cpu, event);
>
> mutex_lock(&cpufreq_governor_lock);
> - if ((!policy->governor_enabled && (event == CPUFREQ_GOV_STOP)) ||
> - if (policy->governor_busy
> - || (policy->governor_enabled && event == CPUFREQ_GOV_START)
> - || (!policy->governor_enabled
> - && (event == CPUFREQ_GOV_LIMITS || event == CPUFREQ_GOV_STOP))) {
> ++ if (policy->governor_busy ||
> ++ (!policy->governor_enabled && (event == CPUFREQ_GOV_STOP)) ||
> + (policy->governor_enabled && (event == CPUFREQ_GOV_START))) {
> mutex_unlock(&cpufreq_governor_lock);
> return -EBUSY;
> }
>
> - a857c0b9e24e3 cpufreq: Fix wrong time unit conversion
>
> As noted in the changelog this is a bugfix for non-tick based
> systems like full dynticks ones.
>
> There's also this:
>
> - dfa5bb622555d cpufreq: ondemand: Change the calculation of target frequency
>
> This is a small patch which delivers a useful performance improvement
> but it's not a bug fix and it does touch the cpufreq core so it
> doesn't seem to really fit. On the other hand I've got user reports
> that it fixes problems with some multicluster systems that can scale
> cluster frequencies independently (the additional stability in the
> frequencies selected avoids poor interaction with scheduler as cpufreq
> ramps the frequency while the scheduler moves load away from the
> cluster), it's simple and it's quite well isolated so I wanted to
> mention it.
>
> Thanks,
> Mark
Attachment:
signature.asc
Description: Digital signature