ARM: sched_clock: Load cycle count after epoch stabilizes
authorStephen Boyd <sboyd@codeaurora.org>
Mon, 17 Jun 2013 22:40:58 +0000 (15:40 -0700)
committerAjay Nandakumar <anandakumarm@nvidia.com>
Mon, 13 Jan 2014 06:33:37 +0000 (11:33 +0530)
commitfdbaed23b16dd817ceb54fe4458193bf920d1c06
treeaa296144aaf8fc577adfa4d05d436c5641388cc4
parent6220dca122e5d31ff3a167d14680e424664b8c7a
ARM: sched_clock: Load cycle count after epoch stabilizes

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

 CPU0                           CPU1
 ----                           ----
 cyc = read_sched_clock()
 cyc_to_sched_clock()
                                 update_sched_clock()
                                  ...
                                  cd.epoch_cyc = cyc;
  epoch_cyc = cd.epoch_cyc;
  ...
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Bug 1399318

Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf)
Signed-off-by: Ajay Nandakumar <anandakumarm@nvidia.com>
Change-Id: I50aedb0eb050206de4ab20505e84a561ec1ca0fb
kernel/time/sched_clock.c