Re: [PATCH V2 2/3] cpufreq: add support for intermediate (stable) frequencies

From: Stephen Warren
Date: Fri May 16 2014 - 14:50:15 EST


On 05/16/2014 03:07 AM, Viresh Kumar wrote:
> Douglas Anderson, recently pointed out an interesting problem due to which
> udelay() was expiring earlier than it should.
>
> While transitioning between frequencies few platforms may temporarily switch to
> a stable frequency, waiting for the main PLL to stabilize.
>
> For example: When we transition between very low frequencies on exynos, like
> between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
> No CPUFREQ notification is sent for that. That means there's a period of time
> when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
> and 300MHz. And so udelay behaves badly.
>
> To get this fixed in a generic way, lets introduce another set of callbacks
> get_intermediate() and target_intermediate(), only for drivers with
> target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.
>
> get_intermediate should return a stable intermediate frequency platform wants to
> switch to, and target_intermediate() should set CPU to to that frequency, before
> jumping to the frequency corresponding to 'index'. Core will take care of
> sending notifications and driver doesn't have to handle them in
> target_intermediate() or target_index().
>
> NOTE: Once set to intermediate frequency, driver isn't expected to fail for the
> following ->target_index() call, if it fails core will issue a WARN().

> diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt

> +cpufreq_driver.get_intermediate
> +and target_intermediate Uset to switch to stable frequency while
> + changing CPU frequency.

s/Uset/Used.

> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h

> @@ -226,6 +226,21 @@ struct cpufreq_driver {

> + unsigned int (*get_intermediate)(struct cpufreq_policy *policy,
> + unsigned int index);

Should get_intermediate be passed a struct cpufreq_freqs freqs rather
than just the target index? That way, if the intermediate frequency
varies depending on old/new frequencies, then the driver won't have to
go look up the current frequency in order to implement that logic.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/