kernel/linux.git/drivers/clocksource/arm_arch_timer.c, branch v6.1.168

clocksource/drivers/arm_arch_timer: Do not use timer namespace for timer_shutdown() function

2025-10-29T13:04:31+00:00

[ Upstream commit 73737a5833ace25a8408b0d3b783637cb6bf29d1 ] A new "shutdown" timer state is being added to the generic timer code. One of the functions to change the timer into the state is called "timer_shutdown()". This means that there can not be other functions called "timer_shutdown()" as the timer code owns the "timer_*" name space. Rename timer_shutdown() to arch_timer_shutdown() to avoid this conflict. Signed-off-by: Steven Rostedt (Google) Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Reviewed-by: Guenter Roeck Reviewed-by: Jacob Keller Reviewed-by: Anna-Maria Behnsen Acked-by: Marc Zyngier Link: https://lkml.kernel.org/r/20221106212702.002251651@goodmis.org Link: https://lore.kernel.org/all/20221105060155.409832154@goodmis.org/ Link: https://lore.kernel.org/r/20221110064146.981725531@goodmis.org Link: https://lore.kernel.org/r/20221123201624.574672568@linutronix.de Signed-off-by: Jeongjun Park Signed-off-by: Greg Kroah-Hartman

clocksource/drivers/arm_arch_timer: limit XGene-1 workaround

2023-11-20T10:52:01+00:00

[ Upstream commit 851354cbd12bb9500909733c3d4054306f61df87 ] The AppliedMicro XGene-1 CPU has an erratum where the timer condition would only consider TVAL, not CVAL. We currently apply a workaround when seeing the PartNum field of MIDR_EL1 being 0x000, under the assumption that this would match only the XGene-1 CPU model. However even the Ampere eMAG (aka XGene-3) uses that same part number, and only differs in the "Variant" and "Revision" fields: XGene-1's MIDR is 0x500f0000, our eMAG reports 0x503f0002. Experiments show the latter doesn't show the faulty behaviour. Increase the specificity of the check to only consider partnum 0x000 and variant 0x00, to exclude the Ampere eMAG. Fixes: 012f18850452 ("clocksource/drivers/arm_arch_timer: Work around broken CVAL implementations") Reported-by: Ross Burton Signed-off-by: Andre Przywara Acked-by: Marc Zyngier Reviewed-by: Oliver Upton Link: https://lore.kernel.org/r/20231016153127.116101-1-andre.przywara@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

clocksource/drivers/arm_arch_timer: Disable timer before programming CVAL

2023-09-19T10:28:04+00:00

commit e7d65e40ab5a5940785c5922f317602d0268caaf upstream. Due to the fact that the use of `writeq_relaxed()` to program CVAL is not guaranteed to be atomic, it is necessary to disable the timer before programming CVAL. However, if the MMIO timer is already enabled and has not yet expired, there is a possibility of unexpected behavior occurring: when the CPU enters the idle state during this period, and if the CPU's local event is earlier than the broadcast event, the following process occurs: tick_broadcast_enter() tick_broadcast_oneshot_control(TICK_BROADCAST_ENTER) __tick_broadcast_oneshot_control() ___tick_broadcast_oneshot_control() tick_broadcast_set_event() clockevents_program_event() set_next_event_mem() During this process, the MMIO timer remains enabled while programming CVAL. To prevent such behavior, disable timer explicitly prior to programming CVAL. Fixes: 8b82c4f883a7 ("clocksource/drivers/arm_arch_timer: Move MMIO timer programming over to CVAL") Cc: stable@vger.kernel.org Signed-off-by: Walter Chang Acked-by: Marc Zyngier Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20230717090735.19370-1-walter.chang@mediatek.com Signed-off-by: Greg Kroah-Hartman

clocksource/drivers/arm_arch_timer: Fix XGene-1 TVAL register math error

2022-11-21T15:01:56+00:00

The TVAL register is 32 bit signed. Thus only the lower 31 bits are available to specify when an interrupt is to occur at some time in the near future. Attempting to specify a larger interval with TVAL results in a negative time delta which means the timer fires immediately upon being programmed, rather than firing at that expected future time. The solution is for Linux to declare that TVAL is a 31 bit register rather than give its true size of 32 bits. This prevents Linux from programming TVAL with a too-large value. Note that, prior to 5.16, this little trick was the standard way to handle TVAL in Linux, so there is nothing new happening here on that front. The softlockup detector hides the issue, because it keeps generating short timer deadlines that are within the scope of the broken timer. Disabling it, it starts using NO_HZ with much longer timer deadlines, which turns into an interrupt flood: 11: 1124855130 949168462 758009394 76417474 104782230 30210281 310890 1734323687 GICv2 29 Level arch_timer And "much longer" isn't that long: it takes less than 43s to underflow TVAL at 50MHz (the frequency of the counter on XGene-1). Some comments on the v1 version of this patch by Marc Zyngier: XGene implements CVAL (a 64bit comparator) in terms of TVAL (a countdown register) instead of the other way around. TVAL being a 32bit register, the width of the counter should equally be 32. However, TVAL is a *signed* value, and keeps counting down in the negative range once the timer fires. It means that any TVAL value with bit 31 set will fire immediately, as it cannot be distinguished from an already expired timer. Reducing the timer range back to a paltry 31 bits papers over the issue. Another problem cannot be fixed though, which is that the timer interrupt *must* be handled within the negative countdown period, or the interrupt will be lost (TVAL will rollover to a positive value, indicative of a new timer deadline). Fixes: 012f18850452 ("clocksource/drivers/arm_arch_timer: Work around broken CVAL implementations") Signed-off-by: Joe Korty Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20221024165422.GA51107@zipoli.concurrent-rt.com Link: https://lore.kernel.org/r/20221121145343.896018-1-maz@kernel.org [maz: revamped the commit message]

clocksource/drivers/arm_arch_timer: Fix CNTPCT_LO and CNTVCT_LO value

2022-09-27T09:30:53+00:00

CNTPCT_LO and CNTVCT_LO are defined by mistake in commit '8b82c4f883a7', so fix them according to the Arm ARM DDI 0487I.a, Table I2-4 "CNTBaseN memory map" as follows: Offset Register Type Description 0x000 CNTPCT[31:0] RO Physical Count register. 0x004 CNTPCT[63:32] RO 0x008 CNTVCT[31:0] RO Virtual Count register. 0x00C CNTVCT[63:32] RO Fixes: 8b82c4f883a7 ("clocksource/drivers/arm_arch_timer: Move MMIO timer programming over to CVAL") Cc: stable@vger.kernel.org Cc: Daniel Lezcano Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Mark Rutland Acked-by: Marc Zyngier Signed-off-by: Yang Guo Signed-off-by: Shaokun Zhang Link: https://lore.kernel.org/r/20220927033221.49589-1-zhangshaokun@hisilicon.com Signed-off-by: Daniel Lezcano

clocksource/drivers/arm_arch_timer: Fix handling of ARM erratum 858921

2022-09-20T08:49:45+00:00

The commit a38b71b0833e ("clocksource/drivers/arm_arch_timer: Move system register timer programming over to CVAL") moves the programming of the timers from the countdown timer (TVAL) over to the comparator (CVAL). This makes it necessary to read the counter when programming next event. However, the workaround of Cortex-A73 erratum 858921 does not set the corresponding set_next_event_phys and set_next_event_virt. Add the appropriate hooks to apply the erratum mitigation when programming the next timer event. Fixes: a38b71b0833e ("clocksource/drivers/arm_arch_timer: Move system register timer programming over to CVAL") Signed-off-by: Kunkun Jiang Acked-by: Marc Zyngier Reviewed-by: Oliver Upton Link: https://lore.kernel.org/r/20220914061424.1260-1-jiangkunkun@huawei.com Signed-off-by: Daniel Lezcano

clocksource/drivers/arm_arch_timer: Use event stream scaling when available

2022-03-07T17:27:22+00:00

With FEAT_ECV and the 1GHz counter, it is pretty likely that the event stream divider doesn't fit in the field that holds the divider value (we only have 4 bits to describe counter bits [15:0] Thankfully, FEAT_ECV also provides a scaling mechanism to switch the field to cover counter bits [23:8] instead. Enable this on arm64 when ECV is available (32bit doesn't have any detection infrastructure and is unlikely to be run on an ARMv8.6 system anyway). Signed-off-by: Marc Zyngier Cc: Mark Rutland Cc: Daniel Lezcano Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20220203170502.2694422-1-maz@kernel.org Signed-off-by: Daniel Lezcano

clocksource/drivers/arm_arch_timer: Force inlining of erratum_set_next_event_generic()

2021-12-10T16:47:00+00:00

With some specific kernel configuration and Clang, the kernel fails to like with something like: ld.lld: error: undefined symbol: __compiletime_assert_200 >>> referenced by arch_timer.h:156 (./arch/arm64/include/asm/arch_timer.h:156) >>> clocksource/arm_arch_timer.o:(erratum_set_next_event_generic) in archive drivers/built-in.a ld.lld: error: undefined symbol: __compiletime_assert_197 >>> referenced by arch_timer.h:133 (./arch/arm64/include/asm/arch_timer.h:133) >>> clocksource/arm_arch_timer.o:(erratum_set_next_event_generic) in archive drivers/built-in.a make: *** [Makefile:1161: vmlinux] Error 1 These are due to the BUILD_BUG() macros contained in the low-level accessors (arch_timer_reg_{write,read}_cp15) being emitted, as the access type wasn't known at compile time. Fix this by making erratum_set_next_event_generic() __force_inline, resulting in the 'access' parameter to be resolved at compile time, similarly to what is already done for set_next_event(). Fixes: 4775bc63f880 ("Add build-time guards for unhandled register accesses") Reported-by: Greg Kroah-Hartman Signed-off-by: Marc Zyngier Cc: Mark Rutland Cc: Daniel Lezcano Cc: Sami Tolvanen Cc: Nick Desaulniers Tested-by: Sami Tolvanen Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/20211117113532.3895208-1-maz@kernel.org Signed-off-by: Daniel Lezcano

clocksource/drivers/arm_arch_timer: Fix masking for high freq counters

2021-10-18T07:20:02+00:00

Unfortunately, the architecture provides no means to determine the bit width of the system counter. However, we do know the following from the specification: - the system counter is at least 56 bits wide - Roll-over time of not less than 40 years To date, the arch timer driver has depended on the first property, assuming any system counter to be 56 bits wide and masking off the rest. However, combining a narrow clocksource mask with a high frequency counter could result in prematurely wrapping the system counter by a significant margin. For example, a 56 bit wide, 1GHz system counter would wrap in a mere 2.28 years! This is a problem for two reasons: v8.6+ implementations are required to provide a 64 bit, 1GHz system counter. Furthermore, before v8.6, implementers may select a counter frequency of their choosing. Fix the issue by deriving a valid clock mask based on the second property from above. Set the floor at 56 bits, since we know no system counter is narrower than that. [maz: fixed width computation not to lose the last bit, added max delta generation for the timer] Suggested-by: Marc Zyngier Signed-off-by: Oliver Upton Reviewed-by: Linus Walleij Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210807191428.3488948-1-oupton@google.com Link: https://lore.kernel.org/r/20211017124225.3018098-13-maz@kernel.org Signed-off-by: Daniel Lezcano

clocksource/drivers/arm_arch_timer: Remove any trace of the TVAL programming interface

2021-10-17T19:47:39+00:00

TVAL usage is now long gone, get rid of the leftovers. Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20211017124225.3018098-11-maz@kernel.org Signed-off-by: Daniel Lezcano