summaryrefslogtreecommitdiff
path: root/arch
diff options
context:
space:
mode:
authorChirantan Ekbote <chirantan@chromium.org>2014-06-12 00:18:48 +0900
committerChanho Park <chanho61.park@samsung.com>2014-11-18 12:01:00 +0900
commit69baf4e96a2755004f4d60a2c3a6d23242ef11a7 (patch)
treeb5d49b5d3fd689baa1bfa1fe931243ffa2c0f7eb /arch
parentefb2fe37fef06dc657fa6e751f199b973d314437 (diff)
downloadlinux-3.10-69baf4e96a2755004f4d60a2c3a6d23242ef11a7.tar.gz
linux-3.10-69baf4e96a2755004f4d60a2c3a6d23242ef11a7.tar.bz2
linux-3.10-69baf4e96a2755004f4d60a2c3a6d23242ef11a7.zip
clocksource: exynos_mct: Don't reset the counter during boot and resume
Unfortunately on some exynos systems, resetting the mct counter also resets the architected timer counter. This can cause problems if the architected timer driver has already been initialized because the kernel will think that the counter has wrapped around, causing a big jump in printk timestamps and delaying any scheduled clock events until the counter reaches the value it had before it was reset. The kernel code makes no assumptions about the initial value of the mct counter so there is no reason from a software perspective to clear the counter before starting it. This also fixes the problems described in the previous paragraph. Change-Id: I35f6bcd1e0ef46d5c19183dc526078a6b8b4ca64 Cc: Olof Johansson <olof@lixom.net> Cc: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Chirantan Ekbote <chirantan@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions