summaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorZoran Markovic <zoran.markovic@linaro.org>2013-05-17 20:24:05 +0200
committerJohn Stultz <john.stultz@linaro.org>2013-05-28 22:45:19 +0200
commit0d6bd9953f739dad96d9a0de65383e479ab4e10d (patch)
tree0f053972369289c5368f67af03a420b8c725828d /drivers
parentntp: Remove unused variable flags in __hardpps (diff)
downloadlinux-0d6bd9953f739dad96d9a0de65383e479ab4e10d.tar.xz
linux-0d6bd9953f739dad96d9a0de65383e479ab4e10d.zip
timekeeping: Correct run-time detection of persistent_clock.
Since commit 31ade30692dc9680bfc95700d794818fa3f754ac, timekeeping_init() checks for presence of persistent clock by attempting to read a non-zero time value. This is an issue on platforms where persistent_clock (instead is implemented as a free-running counter (instead of an RTC) starting from zero on each boot and running during suspend. Examples are some ARM platforms (e.g. PandaBoard). An attempt to read such a clock during timekeeping_init() may return zero value and falsely declare persistent clock as missing. Additionally, in the above case suspend times may be accounted twice (once from timekeeping_resume() and once from rtc_resume()), resulting in a gradual drift of system time. This patch does a run-time correction of the issue by doing the same check during timekeeping_suspend(). A better long-term solution would have to return error when trying to read non-existing clock and zero when trying to read an uninitialized clock, but that would require changing all persistent_clock implementations. This patch addresses the immediate breakage, for now. Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Feng Tang <feng.tang@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org> [jstultz: Tweaked commit message and subject] Signed-off-by: John Stultz <john.stultz@linaro.org>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions