Re: Potential cpufreq backports for v3.10 LTS

Mark Brown <[email protected]> Tue, 7 Oct 2014 13:14:14 +0100
Newsgroups	org.kernel.vger.cpufreq,org.kernel.vger.linux-pm
Message-ID	<[email protected]>
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
signature.asc (application/pgp-signature, 473 B)