summaryrefslogtreecommitdiff
path: root/drivers/clocksource/h8300_timer16.c
diff options
context:
space:
mode:
authorSergei Shtylyov <sergei.shtylyov@cogentembedded.com>2018-09-08 23:54:05 +0300
committerDaniel Lezcano <daniel.lezcano@linaro.org>2018-10-03 15:36:57 +0300
commit22627c6f3ed3d9d0df13eec3c831b08f8186c38e (patch)
treee33b069603fd54cd147e05061ccd82a4bed52724 /drivers/clocksource/h8300_timer16.c
parent0b9294fe8dca4ab500e955cf06445134d228e493 (diff)
downloadlinux-22627c6f3ed3d9d0df13eec3c831b08f8186c38e.tar.xz
clocksource/drivers/sh_cmt: Fixup for 64-bit machines
When trying to use CMT for clockevents on R-Car gen3 SoCs, I noticed that 'max_delta_ns' for the broadcast timer (CMT) was shown as 1000 in /proc/timer_list. It turned out that when calculating it, the driver did 1 << 32 (causing what I think was undefined behavior) resulting in a zero delta, later clamped to 1000 by cev_delta2ns(). The root cause turned out to be that the driver abused *unsigned long* for the CMT register values (which are 16/32-bit), so that the calculation of 'ch->max_match_value' in sh_cmt_setup_channel() used the wrong branch. Using more proper 'u32' instead fixed 'max_delta_ns' and even fixed the switching an active clocksource to CMT (which caused the system to turn non-interactive before). Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Diffstat (limited to 'drivers/clocksource/h8300_timer16.c')
0 files changed, 0 insertions, 0 deletions