From: Viresh Kumar <viresh.kumar@linaro.org>
To: rjw@rjwysocki.net
Cc: linaro-kernel@lists.linaro.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
srivatsa.bhat@linux.vnet.ibm.com,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: [PATCH V4 0/3] cpufreq: Introduce cpufreq_freq_transition_{begin|end}()
Date: Fri, 21 Mar 2014 11:04:29 +0530 [thread overview]
Message-ID: <cover.1395379422.git.viresh.kumar@linaro.org> (raw)
Whenever we change the frequency of a CPU, we call the PRECHANGE and POSTCHANGE
notifiers. They must be serialized, i.e. PRECHANGE and POSTCHANGE notifiers
should strictly alternate, thereby preventing two different sets of PRECHANGE or
POSTCHANGE notifiers from interleaving arbitrarily.
The following examples illustrate why this is important:
Scenario 1:
-----------
A thread reading the value of cpuinfo_cur_freq, will call
__cpufreq_cpu_get()->cpufreq_out_of_sync()->cpufreq_notify_transition()
The ondemand governor can decide to change the frequency of the CPU at the same
time and hence it can end up sending the notifications via ->target().
If the notifiers are not serialized, the following sequence can occur:
- PRECHANGE Notification for freq A (from cpuinfo_cur_freq)
- PRECHANGE Notification for freq B (from target())
- Freq changed by target() to B
- POSTCHANGE Notification for freq B
- POSTCHANGE Notification for freq A
We can see from the above that the last POSTCHANGE Notification happens for freq
A but the hardware is set to run at freq B.
Where would we break then?: adjust_jiffies() in cpufreq.c & cpufreq_callback()
in arch/arm/kernel/smp.c (which also adjusts the jiffies). All the
loops_per_jiffy calculations will get messed up.
Scenario 2:
-----------
The governor calls __cpufreq_driver_target() to change the frequency. At the
same time, if we change scaling_{min|max}_freq from sysfs, it will end up
calling the governor's CPUFREQ_GOV_LIMITS notification, which will also call
__cpufreq_driver_target(). And hence we end up issuing concurrent calls to
->target().
Typically, platforms have the following logic in their ->target() routines:
(Eg: cpufreq-cpu0, omap, exynos, etc)
A. If new freq is more than old: Increase voltage
B. Change freq
C. If new freq is less than old: decrease voltage
Now, if the two concurrent calls to ->target() are X and Y, where X is trying to
increase the freq and Y is trying to decrease it, we get the following race
condition:
X.A: voltage gets increased for larger freq
Y.A: nothing happens
Y.B: freq gets decreased
Y.C: voltage gets decreased
X.B: freq gets increased
X.C: nothing happens
Thus we can end up setting a freq which is not supported by the voltage we have
set. That will probably make the clock to the CPU unstable and the system might
not work properly anymore.
This patchset introduces a new set of routines cpufreq_freq_transition_begin()
and cpufreq_freq_transition_end(), which will guarantee that calls to frequency
transition routines are serialized. Later patches force other drivers to use
these new routines.
Srivatsa S. Bhat (1):
cpufreq: Make sure frequency transitions are serialized
Viresh Kumar (2):
cpufreq: Convert existing drivers to use
cpufreq_freq_transition_{begin|end}
cpufreq: Make cpufreq_notify_transition &
cpufreq_notify_post_transition static
drivers/cpufreq/cpufreq-nforce2.c | 4 +--
drivers/cpufreq/cpufreq.c | 52 +++++++++++++++++++++++++++++-------
drivers/cpufreq/exynos5440-cpufreq.c | 4 +--
drivers/cpufreq/gx-suspmod.c | 4 +--
drivers/cpufreq/integrator-cpufreq.c | 4 +--
drivers/cpufreq/longhaul.c | 4 +--
drivers/cpufreq/pcc-cpufreq.c | 4 +--
drivers/cpufreq/powernow-k6.c | 4 +--
drivers/cpufreq/powernow-k7.c | 4 +--
drivers/cpufreq/powernow-k8.c | 4 +--
drivers/cpufreq/s3c24xx-cpufreq.c | 4 +--
drivers/cpufreq/sh-cpufreq.c | 4 +--
drivers/cpufreq/unicore2-cpufreq.c | 4 +--
include/linux/cpufreq.h | 12 ++++++---
14 files changed, 76 insertions(+), 36 deletions(-)
--
1.7.12.rc2.18.g61b472e
next reply other threads:[~2014-03-21 5:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 5:34 Viresh Kumar [this message]
2014-03-21 5:34 ` [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized Viresh Kumar
2014-03-21 7:46 ` Srivatsa S. Bhat
2014-03-21 7:58 ` Viresh Kumar
2014-03-21 8:42 ` Srivatsa S. Bhat
2014-03-21 9:21 ` Viresh Kumar
2014-03-21 10:06 ` Viresh Kumar
2014-03-21 11:05 ` Catalin Marinas
2014-03-21 11:24 ` Srivatsa S. Bhat
2014-03-21 18:07 ` Catalin Marinas
2014-03-22 3:48 ` Viresh Kumar
2014-03-24 6:48 ` Srivatsa S. Bhat
2014-03-24 6:19 ` Viresh Kumar
2014-03-21 5:34 ` [PATCH V4 2/3] cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end} Viresh Kumar
2014-03-21 7:48 ` Srivatsa S. Bhat
2014-03-21 7:59 ` Viresh Kumar
2014-03-21 5:34 ` [PATCH V4 3/3] cpufreq: Make cpufreq_notify_transition & cpufreq_notify_post_transition static Viresh Kumar
2014-03-21 7:51 ` Srivatsa S. Bhat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1395379422.git.viresh.kumar@linaro.org \
--to=viresh.kumar@linaro.org \
--cc=cpufreq@vger.kernel.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).