diff options
| author | Sergei Shtylyov <[email protected]> | 2018-09-08 20:54:05 +0000 |
|---|---|---|
| committer | Daniel Lezcano <[email protected]> | 2018-10-03 12:36:57 +0000 |
| commit | 22627c6f3ed3d9d0df13eec3c831b08f8186c38e (patch) | |
| tree | e33b069603fd54cd147e05061ccd82a4bed52724 /drivers/clocksource/qcom-timer.c | |
| parent | clocksource/drivers/sh_tmu: Convert to SPDX identifiers (diff) | |
| download | kernel-22627c6f3ed3d9d0df13eec3c831b08f8186c38e.tar.gz kernel-22627c6f3ed3d9d0df13eec3c831b08f8186c38e.zip | |
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 <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Diffstat (limited to 'drivers/clocksource/qcom-timer.c')
0 files changed, 0 insertions, 0 deletions