#
b152688c |
|
31-Jan-2024 |
Peter Hilber <peter.hilber@opensynergy.com> |
treewide: Remove system_counterval_t.cs, which is never read The clocksource pointer in struct system_counterval_t is not evaluated any more. Remove the code setting the member, and the member itself. Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240201010453.2212371-8-peter.hilber@opensynergy.com
|
#
9be3b2f0 |
|
31-Jan-2024 |
Peter Hilber <peter.hilber@opensynergy.com> |
ptp/kvm, arm_arch_timer: Set system_counterval_t.cs_id to constant Identify the clocksources used by ptp_kvm by setting the clocksource ID enum constants. This avoids dereferencing struct clocksource. Once the system_counterval_t.cs member will be removed, this will also avoid the need to obtain clocksource pointers from kvm_arch_ptp_get_crosststamp(). The clocksource IDs are associated to timestamps requested from the KVM hypervisor, so the proper clocksource ID is known at the ptp_kvm request site. While at it, also make the ptp_kvm_get_time_fn() 'ret' variable type int as that's what the function return value is. Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240201010453.2212371-6-peter.hilber@opensynergy.com
|
#
851354cb |
|
16-Oct-2023 |
Andre Przywara <andre.przywara@arm.com> |
clocksource/drivers/arm_arch_timer: limit XGene-1 workaround 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 <ross.burton@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20231016153127.116101-1-andre.przywara@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
166b76a0 |
|
16-Oct-2023 |
Mark Rutland <mark.rutland@arm.com> |
clocksource/drivers/arm_arch_timer: Initialize evtstrm after finalizing cpucaps We attempt to initialize each CPU's arch_timer event stream in arch_timer_evtstrm_enable(), which we call from the arch_timer_starting_cpu() cpu hotplug callback which is registered early in boot. As this is registered before we initialize the system cpucaps, the test for ARM64_HAS_ECV will always be false for CPUs present at boot time, and will only be taken into account for CPUs onlined late (including those which are hotplugged out and in again). Due to this, CPUs present and boot time may not use the intended divider and scale factor to generate the event stream, and may differ from other CPUs. Correct this by only initializing the event stream after cpucaps have been finalized, registering a separate CPU hotplug callback for the event stream configuration. Since the caps must be finalized by this point, use cpus_have_final_cap() to verify this. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
e7d65e40 |
|
17-Jul-2023 |
Walter Chang <walter.chang@mediatek.com> |
clocksource/drivers/arm_arch_timer: Disable timer before programming CVAL 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 <walter.chang@mediatek.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20230717090735.19370-1-walter.chang@mediatek.com
|
#
5416bf1c |
|
06-Jun-2023 |
Peter Zijlstra <peterz@infradead.org> |
arm64/arch_timer: Fix MMIO byteswap The readl_relaxed() to __raw_readl() change meant to loose the instrumentation, but also (inadvertently) lost the byteswap. Fixes: 24ee7607b286 ("arm64/arch_timer: Provide noinstr sched_clock_read() functions") Reported-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lkml.kernel.org/r/20230606080614.GB905437@hirez.programming.kicks-ass.net
|
#
24ee7607 |
|
18-May-2023 |
Peter Zijlstra <peterz@infradead.org> |
arm64/arch_timer: Provide noinstr sched_clock_read() functions With the intent to provide local_clock_noinstr(), a variant of local_clock() that's safe to be called from noinstr code (with the assumption that any such code will already be non-preemptible), prepare for things by providing a noinstr sched_clock_read() function. Specifically, preempt_enable_*() calls out to schedule(), which upsets noinstr validation efforts. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Michael Kelley <mikelley@microsoft.com> # Hyper-V Link: https://lore.kernel.org/r/20230519102715.435618812@infradead.org
|
#
42385687 |
|
01-Nov-2022 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
clocksource/drivers/arm_arch_timer: Use kstrtobool() instead of strtobool() strtobool() is the same as kstrtobool(). However, the latter is more used within the kernel. In order to remove strtobool() and slightly simplify kstrtox.h, switch to the other function name. While at it, include the corresponding header file (<linux/kstrtox.h>) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/f430bb12e12eb225ab1206db0be64b755ddafbdc.1667336095.git.christophe.jaillet@wanadoo.fr Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
|
#
45ae272a |
|
21-Nov-2022 |
Joe Korty <joe.korty@concurrent-rt.com> |
clocksource/drivers/arm_arch_timer: Fix XGene-1 TVAL register math error 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. Disable it, and you start 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). Cc: stable@vger.kernel.org # 5.16+ Fixes: 012f18850452 ("clocksource/drivers/arm_arch_timer: Work around broken CVAL implementations") Signed-off-by: Joe Korty <joe.korty@concurrent-rt.com> Reviewed-by: Marc Zyngier <maz@kernel.org> [maz: revamped the commit message] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221024165422.GA51107@zipoli.concurrent-rt.com Link: https://lore.kernel.org/r/20221121145343.896018-1-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
|
#
73737a58 |
|
23-Nov-2022 |
Steven Rostedt (Google) <rostedt@goodmis.org> |
clocksource/drivers/arm_arch_timer: Do not use timer namespace for timer_shutdown() function 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) <rostedt@goodmis.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Acked-by: Marc Zyngier <maz@kernel.org> 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
|
#
839a9739 |
|
21-Nov-2022 |
Joe Korty <joe.korty@concurrent-rt.com> |
clocksource/drivers/arm_arch_timer: Fix XGene-1 TVAL register math error 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 <joe.korty@concurrent-rt.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Marc Zyngier <maz@kernel.org> 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]
|
#
af246cc6 |
|
26-Sep-2022 |
Yang Guo <guoyang2@huawei.com> |
clocksource/drivers/arm_arch_timer: Fix CNTPCT_LO and CNTVCT_LO value 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 <daniel.lezcano@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Yang Guo <guoyang2@huawei.com> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Link: https://lore.kernel.org/r/20220927033221.49589-1-zhangshaokun@hisilicon.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
6c3b62d9 |
|
14-Sep-2022 |
Kunkun Jiang <jiangkunkun@huawei.com> |
clocksource/drivers/arm_arch_timer: Fix handling of ARM erratum 858921 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 <jiangkunkun@huawei.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20220914061424.1260-1-jiangkunkun@huawei.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
8c4b810a |
|
03-Feb-2022 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Use event stream scaling when available 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 <maz@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220203170502.2694422-1-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
1edb7e74 |
|
17-Nov-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Force inlining of erratum_set_next_event_generic() 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 <gregkh@linuxfoundation.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211117113532.3895208-1-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
c1153d52 |
|
17-Oct-2021 |
Oliver Upton <oupton@google.com> |
clocksource/drivers/arm_arch_timer: Fix masking for high freq counters 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 <maz@kernel.org> Signed-off-by: Oliver Upton <oupton@google.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marc Zyngier <maz@kernel.org> 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 <daniel.lezcano@linaro.org>
|
#
41f8d02a |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Remove any trace of the TVAL programming interface TVAL usage is now long gone, get rid of the leftovers. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-11-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
012f1885 |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Work around broken CVAL implementations The Applied Micro XGene-1 SoC has a busted implementation of the CVAL register: it looks like it is based on TVAL instead of the other way around. The net effect of this implementation blunder is that the maximum deadline you can program in the timer is 32bit wide. Use a MIDR check to notice the broken CPU, and reduce the width of the timer to 32bit. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-10-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
30aa08da |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Advertise 56bit timer to the core code Proudly tell the code code that we have a timer able to handle 56 bits deltas. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-9-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
8b82c4f8 |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Move MMIO timer programming over to CVAL Similarily to the sysreg-based timer, move the MMIO over to using the CVAL registers instead of TVAL. Note that there is no warranty that the 64bit MMIO access will be atomic, but the timer is always disabled at the point where we program CVAL. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-8-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
72f47a3f |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Fix MMIO base address vs callback ordering issue The MMIO timer base address gets published after we have registered the callbacks and the interrupt handler, which is... a bit dangerous. Fix this by moving the base address publication to the point where we register the timer, and expose a pointer to the timer structure itself rather than a naked value. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-7-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
ac9ef4f2 |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Move drop _tval from erratum function names The '_tval' name in the erratum handling function names doesn't make much sense anymore (and they were using CVAL the first place). Drop the _tval tag. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-6-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
a38b71b0 |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Move system register timer programming over to CVAL In order to cope better with high frequency counters, move the programming of the timers from the countdown timer (TVAL) over to the comparator (CVAL). The programming model is slightly different, as we now need to read the current counter value to have an absolute deadline instead of a relative one. There is a small overhead to this change, which we will address in the following patches. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-5-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
1e8d9292 |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Extend write side of timer register accessors to u64 The various accessors for the timer sysreg and MMIO registers are currently hardwired to 32bit. However, we are about to introduce the use of the CVAL registers, which require a 64bit access. Upgrade the write side of the accessors to take a 64bit value (the read side is left untouched as we don't plan to ever read back any of these registers). No functional change expected. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-4-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
d7268998 |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/drivers/arm_arch_timer: Drop CNT*_TVAL read accessors The arch timer driver never reads the various TVAL registers, only writes to them. It is thus pointless to provide accessors for them and to implement errata workarounds. Drop these read-side accessors, and add a couple of BUG() statements for the time being. These statements will be removed further down the line. Reviewed-by: Oliver Upton <oupton@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-3-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
4775bc63 |
|
17-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
clocksource/arm_arch_timer: Add build-time guards for unhandled register accesses As we are about to change the registers that are used by the driver, start by adding build-time checks to ensure that we always handle all registers and access modes. Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-2-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
8b33dfe0 |
|
14-May-2021 |
Samuel Holland <samuel@sholland.org> |
clocksource/arm_arch_timer: Improve Allwinner A64 timer workaround Bad counter reads are experienced sometimes when bit 10 or greater rolls over. Originally, testing showed that at least 10 lower bits would be set to the same value during these bad reads. However, some users still reported time skips. Wider testing revealed that on some chips, occasionally only the lowest 9 bits would read as the anomalous value. During these reads (which still happen only when bit 10), bit 9 would read as the correct value. Reduce the mask by one bit to cover these cases as well. Cc: stable@vger.kernel.org Fixes: c950ca8c35ee ("clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability") Reported-by: Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210515021439.55316-1-samuel@sholland.org
|
#
4f9f4f0f |
|
11-May-2021 |
Jisheng Zhang <Jisheng.Zhang@synaptics.com> |
clocksource/drivers/arm_arch_timer: Remove arch_timer_rate1 This variable is added by my mistake, it's not used at all. Fixes: e2bf384d4329 ("clocksource/drivers/arm_arch_timer: Add __ro_after_init and __init") Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Reported-by: Hulk Robot <hulkci@huawei.com> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210511154856.6afbcb65@xhacker.debian
|
#
300bb1fe |
|
08-Dec-2020 |
Jianyong Wu <jianyong.wu@arm.com> |
ptp: arm/arm64: Enable ptp_kvm for arm/arm64 Currently, there is no mechanism to keep time sync between guest and host in arm/arm64 virtualization environment. Time in guest will drift compared with host after boot up as they may both use third party time sources to correct their time respectively. The time deviation will be in order of milliseconds. But in some scenarios,like in cloud environment, we ask for higher time precision. kvm ptp clock, which chooses the host clock source as a reference clock to sync time between guest and host, has been adopted by x86 which takes the time sync order from milliseconds to nanoseconds. This patch enables kvm ptp clock for arm/arm64 and improves clock sync precision significantly. Test result comparisons between with kvm ptp clock and without it in arm/arm64 are as follows. This test derived from the result of command 'chronyc sources'. we should take more care of the last sample column which shows the offset between the local clock and the source at the last measurement. no kvm ptp in guest: MS Name/IP address Stratum Poll Reach LastRx Last sample ======================================================================== ^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/- 21ms ^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/- 21ms in host: MS Name/IP address Stratum Poll Reach LastRx Last sample ======================================================================== ^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/- 18ms ^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/- 17ms ^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/- 17ms The dns1.synet.edu.cn is the network reference clock for guest and 120.25.115.20 is the network reference clock for host. we can't get the clock error between guest and host directly, but a roughly estimated value will be in order of hundreds of us to ms. with kvm ptp in guest: chrony has been disabled in host to remove the disturb by network clock. MS Name/IP address Stratum Poll Reach LastRx Last sample ======================================================================== * PHC0 0 3 377 8 -7ns[ +1ns] +/- 3ns * PHC0 0 3 377 8 +1ns[ +16ns] +/- 3ns * PHC0 0 3 377 6 -4ns[ -0ns] +/- 6ns * PHC0 0 3 377 6 -8ns[ -12ns] +/- 5ns * PHC0 0 3 377 5 +2ns[ +4ns] +/- 4ns * PHC0 0 3 377 13 +2ns[ +4ns] +/- 4ns * PHC0 0 3 377 12 -4ns[ -6ns] +/- 4ns * PHC0 0 3 377 11 -8ns[ -11ns] +/- 6ns * PHC0 0 3 377 10 -14ns[ -20ns] +/- 4ns * PHC0 0 3 377 8 +4ns[ +5ns] +/- 4ns The PHC0 is the ptp clock which choose the host clock as its source clock. So we can see that the clock difference between host and guest is in order of ns. Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201209060932.212364-8-jianyong.wu@arm.com
|
#
100148d0 |
|
08-Dec-2020 |
Jianyong Wu <jianyong.wu@arm.com> |
clocksource: Add clocksource id for arm arch counter Add clocksource id to the ARM generic counter so that it can be easily identified from callers such as ptp_kvm. Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201209060932.212364-6-jianyong.wu@arm.com
|
#
e2bf384d |
|
30-Mar-2021 |
Jisheng Zhang <Jisheng.Zhang@synaptics.com> |
clocksource/drivers/arm_arch_timer: Add __ro_after_init and __init Some functions are not needed after booting, so mark them as __init to move them to the .init section. Some global variables are never modified after init, so can be __ro_after_init. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210330140444.4fb2a7cb@xhacker.debian
|
#
86332e9e |
|
14-Feb-2021 |
Hector Martin <marcan@marcan.st> |
arm64: arch_timer: Implement support for interrupt-names This allows the devicetree to correctly represent the available set of timers, which varies from device to device, without the need for fake dummy interrupts for unavailable slots. Also add the hyp-virt timer/PPI, which is not currently used, but worth representing. Reviewed-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Hector Martin <marcan@marcan.st>
|
#
8b7770b8 |
|
04-Dec-2020 |
Keqian Zhu <zhukeqian1@huawei.com> |
clocksource/drivers/arm_arch_timer: Correct fault programming of CNTKCTL_EL1.EVNTI ARM virtual counter supports event stream, it can only trigger an event when the trigger bit (the value of CNTKCTL_EL1.EVNTI) of CNTVCT_EL0 changes, so the actual period of event stream is 2^(cntkctl_evnti + 1). For example, when the trigger bit is 0, then virtual counter trigger an event for every two cycles. While we're at it, rework the way we compute the trigger bit position by making it more obvious that when bits [n:n-1] are both set (with n being the most significant bit), we pick bit (n + 1). Fixes: 037f637767a8 ("drivers: clocksource: add support for ARM architected timer event stream") Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201204073126.6920-3-zhukeqian1@huawei.com
|
#
d8cc3905 |
|
04-Dec-2020 |
Keqian Zhu <zhukeqian1@huawei.com> |
clocksource/drivers/arm_arch_timer: Use stable count reader in erratum sne In commit 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter to access stable counters"), we separate stable and normal count reader to omit unnecessary overhead on systems that have no timer erratum. However, in erratum_set_next_event_tval_generic(), count reader becomes normal reader. This converts it to stable reader. Fixes: 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter to access stable counters") Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201204073126.6920-2-zhukeqian1@huawei.com
|
#
4b661d61 |
|
06-Jul-2020 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Disable the compat vdso for cores affected by ARM64_WORKAROUND_1418040 ARM64_WORKAROUND_1418040 requires that AArch32 EL0 accesses to the virtual counter register are trapped and emulated by the kernel. This makes the vdso pretty pointless, and in some cases livelock prone. Provide a workaround entry that limits the vdso to 64bit tasks. Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200706163802.1836732-4-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
c1fbec4a |
|
06-Jul-2020 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Allow an workaround descriptor to disable compat vdso As we are about to disable the vdso for compat tasks in some circumstances, let's allow a workaround descriptor to express exactly that. Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200706163802.1836732-3-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
d1b5e552 |
|
29-Apr-2020 |
Dejin Zheng <zhengdejin5@gmail.com> |
drivers/clocksource/arm_arch_timer: Remove duplicate error message The function acpi_gtdt_init() prints a message in case of error. Remove the error message after testing if the function fails, otherwise it is a duplicate message. Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200429153559.21189-1-zhengdejin5@gmail.com
|
#
c265861a |
|
05-Mar-2020 |
Ionela Voinescu <ionela.voinescu@arm.com> |
clocksource/drivers/arm_arch_timer: validate arch_timer_rate Using an arch timer with a frequency of less than 1MHz can potentially result in incorrect functionality in systems that assume a reasonable rate of the arch timer of 1 to 50MHz, described as typical in the architecture specification. Therefore, warn if the arch timer rate is below 1MHz, which is considered atypical and worth emphasizing. Suggested-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
a67de48b |
|
24-Feb-2020 |
Vincenzo Frascino <vincenzo.frascino@arm.com> |
clocksource/drivers/arm_arch_timer: Fix vDSO clockmode when vDSO disabled The arm_arch_timer requires VDSO_CLOCKMODE_ARCHTIMER to be defined to compile correctly. On ARM the vDSO can be disabled and when this is the case the compilation ends prematurely with an error: $ make ARCH=arm multi_v7_defconfig $ ./scripts/config -d VDSO $ make drivers/clocksource/arm_arch_timer.c:73:44: error: ‘VDSO_CLOCKMODE_ARCHTIMER’ undeclared here (not in a function) static enum vdso_clock_mode vdso_default = VDSO_CLOCKMODE_ARCHTIMER; Make the usage of VDSO_CLOCKMODE_ARCHTIMER depend on the VDSO enablement and initialize the vdso clockmode variable with VDSO_CLOCKMODE_NONE otherwise. [ tglx: Match changelog and patch content. ] Fixes: 5e3c6a312a09 ("ARM/arm64: vdso: Use common vdso clock mode storage") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20200224151552.57274-1-vincenzo.frascino@arm.com
|
#
5e3c6a31 |
|
07-Feb-2020 |
Thomas Gleixner <tglx@linutronix.de> |
ARM/arm64: vdso: Use common vdso clock mode storage Convert ARM/ARM64 to the generic VDSO clock mode storage. This needs to happen in one go as they share the clocksource driver. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lkml.kernel.org/r/20200207124403.363235229@linutronix.de
|
#
5a354412 |
|
13-Jun-2019 |
Andrew Murray <amurray@thegoodpenguin.co.uk> |
clocksource/drivers/arm_arch_timer: Extract elf_hwcap use to arch-helper Different mechanisms are used to test and set elf_hwcaps between ARM and ARM64, this results in the use of ifdeferry in this file when setting/testing for the EVTSTRM hwcap. Let's improve readability by extracting this to an arch helper. Signed-off-by: Andrew Murray <andrew.murray@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
d2912cb1 |
|
04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5d6168fc |
|
24-May-2019 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
clocksource/drivers/arm_arch_timer: Don't trace count reader functions With v5.2-rc1, The ftrace functions_graph tracer locks up whenever it is enabled on arm64. Since commit 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter to access stable counters") a function pointer is consistently used to read the counter instead of potentially referencing an inlinable function. The graph tracers relies on accessing the timer counters to compute the time spent in functions which causes the lockup when attempting to trace these code paths. Annotate the arm arch timer counter accessors as notrace. Fixes: 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter to access stable counters") Signed-off-by: Julien Thierry <julien.thierry@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Steven Rostedt <rostedt@goodmis.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
0ea41539 |
|
08-Apr-2019 |
Marc Zyngier <maz@kernel.org> |
clocksource/arm_arch_timer: Use arch_timer_read_counter to access stable counters Instead of always going via arch_counter_get_cntvct_stable to access the counter workaround, let's have arch_timer_read_counter point to the right method. For that, we need to track whether any CPU in the system has a workaround for the counter. This is done by having an atomic variable tracking this. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
a862fc22 |
|
08-Apr-2019 |
Marc Zyngier <maz@kernel.org> |
clocksource/arm_arch_timer: Remove use of workaround static key The use of a static key in a hotplug path has proved to be a real nightmare, and makes it impossible to have scream-free lockdep kernel. Let's remove the static key altogether, and focus on something saner. Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
5ef19a16 |
|
08-Apr-2019 |
Marc Zyngier <maz@kernel.org> |
clocksource/arm_arch_timer: Direcly assign set_next_event workaround When a given timer is affected by an erratum and requires an alternative implementation of set_next_event, we do a rather complicated dance to detect and call the workaround on each set_next_event call. This is clearly idiotic, as we can perfectly detect whether this CPU requires a workaround while setting up the clock event device. This only requires the CPU-specific detection to be done a bit earlier, and we can then safely override the set_next_event pointer if we have a workaround associated to that CPU. Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by; Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
0f80cad3 |
|
15-Apr-2019 |
Marc Zyngier <maz@kernel.org> |
arm64: Restrict ARM64_ERRATUM_1188873 mitigation to AArch32 We currently deal with ARM64_ERRATUM_1188873 by always trapping EL0 accesses for both instruction sets. Although nothing wrong comes out of that, people trying to squeeze the last drop of performance from buggy HW find this over the top. Oh well. Let's change the mitigation by flipping the counter enable bit on return to userspace. Non-broken HW gets an extra branch on the fast path, which is hopefully not the end of the world. The arch timer workaround is also removed. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
aaba098f |
|
09-Apr-2019 |
Andrew Murray <amurray@thegoodpenguin.co.uk> |
arm64: HWCAP: add support for AT_HWCAP2 As we will exhaust the first 32 bits of AT_HWCAP let's start exposing AT_HWCAP2 to userspace to give us up to 64 caps. Whilst it's possible to use the remaining 32 bits of AT_HWCAP, we prefer to expand into AT_HWCAP2 in order to provide a consistent view to userspace between ILP32 and LP64. However internal to the kernel we prefer to continue to use the full space of elf_hwcap. To reduce complexity and allow for future expansion, we now represent hwcaps in the kernel as ordinals and use a KERNEL_HWCAP_ prefix. This allows us to support automatic feature based module loading for all our hwcaps. We introduce cpu_set_feature to set hwcaps which complements the existing cpu_have_feature helper. These helpers allow us to clean up existing direct uses of elf_hwcap and reduce any future effort required to move beyond 64 caps. For convenience we also introduce cpu_{have,set}_named_feature which makes use of the cpu_feature macro to allow providing a hwcap name without a {KERNEL_}HWCAP_ prefix. Signed-off-by: Andrew Murray <andrew.murray@arm.com> [will: use const_ilog2() and tweak documentation] Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
9155697e |
|
04-Mar-2019 |
Yangtao Li <tiny.windzz@gmail.com> |
clocksource/drivers/arm_arch_timer: Remove unneeded pr_fmt macro After this commit ded24019b6b6f(clocksource: arm_arch_timer: clean up printk usage), the previous macro is redundant, so delete it. And move the new macro to the previous position. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
c950ca8c |
|
12-Jan-2019 |
Samuel Holland <samuel@sholland.org> |
clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability The Allwinner A64 SoC is known[1] to have an unstable architectural timer, which manifests itself most obviously in the time jumping forward a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a timer frequency of 24 MHz, implying that the time went slightly backward (and this was interpreted by the kernel as it jumping forward and wrapping around past the epoch). Investigation revealed instability in the low bits of CNTVCT at the point a high bit rolls over. This leads to power-of-two cycle forward and backward jumps. (Testing shows that forward jumps are about twice as likely as backward jumps.) Since the counter value returns to normal after an indeterminate read, each "jump" really consists of both a forward and backward jump from the software perspective. Unless the kernel is trapping CNTVCT reads, a userspace program is able to read the register in a loop faster than it changes. A test program running on all 4 CPU cores that reported jumps larger than 100 ms was run for 13.6 hours and reported the following: Count | Event -------+--------------------------- 9940 | jumped backward 699ms 268 | jumped backward 1398ms 1 | jumped backward 2097ms 16020 | jumped forward 175ms 6443 | jumped forward 699ms 2976 | jumped forward 1398ms 9 | jumped forward 356516ms 9 | jumped forward 357215ms 4 | jumped forward 714430ms 1 | jumped forward 3578440ms This works out to a jump larger than 100 ms about every 5.5 seconds on each CPU core. The largest jump (almost an hour!) was the following sequence of reads: 0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000 Note that the middle bits don't necessarily all read as all zeroes or all ones during the anomalous behavior; however the low 10 bits checked by the function in this patch have never been observed with any other value. Also note that smaller jumps are much more common, with backward jumps of 2048 (2^11) cycles observed over 400 times per second on each core. (Of course, this is partially explained by lower bits rolling over more frequently.) Any one of these could have caused the 95 year time skip. Similar anomalies were observed while reading CNTPCT (after patching the kernel to allow reads from userspace). However, the CNTPCT jumps are much less frequent, and only small jumps were observed. The same program as before (except now reading CNTPCT) observed after 72 hours: Count | Event -------+--------------------------- 17 | jumped backward 699ms 52 | jumped forward 175ms 2831 | jumped forward 699ms 5 | jumped forward 1398ms Further investigation showed that the instability in CNTPCT/CNTVCT also affected the respective timer's TVAL register. The following values were observed immediately after writing CNVT_TVAL to 0x10000000: CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error --------------------+------------+--------------------+----------------- 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000 The pattern of errors in CNTV_TVAL seemed to depend on exactly which value was written to it. For example, after writing 0x10101010: CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error --------------------+------------+--------------------+----------------- 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000 I was also twice able to reproduce the issue covered by Allwinner's workaround[4], that writing to TVAL sometimes fails, and both CVAL and TVAL are left with entirely bogus values. One was the following values: CNTVCT | CNTV_TVAL | CNTV_CVAL --------------------+------------+-------------------------------------- 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past) Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> ======================================================================== Because the CPU can read the CNTPCT/CNTVCT registers faster than they change, performing two reads of the register and comparing the high bits (like other workarounds) is not a workable solution. And because the timer can jump both forward and backward, no pair of reads can distinguish a good value from a bad one. The only way to guarantee a good value from consecutive reads would be to read _three_ times, and take the middle value only if the three values are 1) each unique and 2) increasing. This takes at minimum 3 counter cycles (125 ns), or more if an anomaly is detected. However, since there is a distinct pattern to the bad values, we can optimize the common case (1022/1024 of the time) to a single read by simply ignoring values that match the error pattern. This still takes no more than 3 cycles in the worst case, and requires much less code. As an additional safety check, we still limit the loop iteration to the number of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods. For the TVAL registers, the simple solution is to not use them. Instead, read or write the CVAL and calculate the TVAL value in software. Although the manufacturer is aware of at least part of the erratum[4], there is no official name for it. For now, use the kernel-internal name "UNKNOWN1". [1]: https://github.com/armbian/build/commit/a08cd6fe7ae9 [2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/ [3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26 [4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272 Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
ee793049 |
|
06-Jul-2018 |
Andre Przywara <andre.przywara@arm.com> |
clocksource/arm_arch_timer: Store physical timer IRQ number for KVM on VHE A host running in VHE mode gets the EL2 physical timer as its time source (accessed using the EL1 sysreg accessors, which get re-directed to the EL2 sysregs by VHE). The EL1 physical timer remains unused by the host kernel, allowing us to pass that on directly to a KVM guest and saves us from emulating this timer for the guest on VHE systems. Store the EL1 Physical Timer's IRQ number in struct arch_timer_kvm_info on VHE systems to allow KVM to use it. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
|
#
95b861a4 |
|
27-Sep-2018 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Add workaround for ARM erratum 1188873 When running on Cortex-A76, a timer access from an AArch32 EL0 task may end up with a corrupted value or register. The workaround for this is to trap these accesses at EL1/EL2 and execute them there. This only affects versions r0p0, r1p0 and r2p0 of the CPU. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
6777996d |
|
02-Aug-2018 |
Thomas Gleixner <tglx@linutronix.de> |
clocksource/drivers/arm_arch_timer: Fix bogus cpu_all_mask usage Using cpu_all_mask as target mask for clockevents is wrong as it never can actually target not possible CPUs. Use cpu_possible_mask instead Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
5e18e412 |
|
09-Jul-2018 |
Sudeep Holla <sudeep.holla@arm.com> |
clocksource: arm_arch_timer: Set arch_mem_timer cpumask to cpu_possible_mask Currently, arch_mem_timer cpumask is set to cpu_all_mask which should be fine. However, cpu_possible_mask is more accurate and if there are other clockevent source in the system which are set to cpu_possible_mask, then having cpu_all_mask may result in issue. E.g. on a platform with arm,sp804 timer with rating 300 and cpu_possible_mask and this arch_mem_timer timer with rating 400 and cpu_all_mask, tick_check_preferred may choose both preferred as the cpumasks are not equal though they must be. This issue was root caused incorrectly initially and a fix was merged as commit 1332a9055801 ("tick: Prefer a lower rating device only if it's CPU local device"). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Link: https://lkml.kernel.org/r/1531151136-18297-2-git-send-email-sudeep.holla@arm.com
|
#
e6d68b00 |
|
05-Jul-2017 |
Christoffer Dall <cdall@linaro.org> |
arm64: Use physical counter for in-kernel reads when booted in EL2 Using the physical counter allows KVM to retain the offset between the virtual and physical counter as long as it is actively running a VCPU. As soon as a VCPU is released, another thread is scheduled or we start running userspace applications, we reset the offset to 0, so that userspace accessing the virtual timer can still read the virtual counter and get the same view of time as the kernel. This opens up potential improvements for KVM performance, but we have to make a few adjustments to preserve system consistency. Currently get_cycles() is hardwired to arch_counter_get_cntvct() on arm64, but as we move to using the physical timer for the in-kernel time-keeping on systems that boot in EL2, we should use the same counter for get_cycles() as for other in-kernel timekeeping operations. Similarly, implementations of arch_timer_set_next_event_phys() is modified to use the counter specific to the timer being programmed. VHE kernels or kernels continuing to use the virtual timer are unaffected. Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
|
#
f2e600c1 |
|
18-Oct-2017 |
Christoffer Dall <christoffer.dall@linaro.org> |
arm64: Implement arch_counter_get_cntpct to read the physical counter As we are about to use the physical counter on arm64 systems that have KVM support, implement arch_counter_get_cntpct() and the associated errata workaround functionality for stable timer reads. Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
#
a7fb4577 |
|
16-Oct-2017 |
Mark Rutland <mark.rutland@arm.com> |
clocksource/drivers/arm_arch_timer: Fix DEFINE_PER_CPU expansion Our ctags mangling script can't handle newlines inside of a DEFINE_PER_CPU(), leading to an annoying message whenever tags are built: ctags: Warning: drivers/clocksource/arm_arch_timer.c:302: null expansion of name pattern "\1" This was dealt with elsewhere in commit: 25528213fe9f75f4 ("tags: Fix DEFINE_PER_CPU expansions") ... by ensuring each DEFINE_PER_CPU() was contained on a single line, even where this would violate the usual code style (checkpatch warnings and all). Let's do the same for the arch timer driver, and get rid of the distraction. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
21492e13 |
|
16-Oct-2017 |
Ard Biesheuvel <ardb@kernel.org> |
clocksource/drivers/arm_arch_timer: Validate CNTFRQ after enabling frame The ACPI GTDT code validates the CNTFRQ field of each MMIO timer frame against the CNTFRQ system register of the current CPU, to ensure that they are equal, which is mandated by the architecture. However, reading the CNTFRQ field of a frame is not possible until the RFRQ bit in the frame's CNTACRn register is set, and doing so before that willl produce the following error: arch_timer: [Firmware Bug]: CNTFRQ mismatch: frame @ 0x00000000e0be0000: (0x00000000), CPU: (0x0ee6b280) arch_timer: Disabling MMIO timers due to CNTFRQ mismatch arch_timer: Failed to initialize memory-mapped timer. The reason is that the CNTFRQ field is RES0 if access is not enabled. So move the validation of CNTFRQ into the loop that iterates over the timers to find the best frame, but defer it until after we have selected the best frame, which should also have enabled the RFRQ bit. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
ec5c8e42 |
|
13-Oct-2017 |
Julien Thierry <julien.thierry.kdev@gmail.com> |
arm_arch_timer: Expose event stream status The arch timer configuration for a CPU might get reset after suspending said CPU. In order to reliably use the event stream in the kernel (e.g. for delays), we keep track of the state where we can safely consider the event stream as properly configured. After writing to cntkctl, we issue an ISB to ensure that subsequent delay loops can rely on the event stream being enabled. Signed-off-by: Julien Thierry <julien.thierry@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
d197f798 |
|
31-Jul-2017 |
Matthias Kaehlcke <mka@chromium.org> |
clocksource/drivers/arm_arch_timer: Fix mem frame loop initialization The loop to find the best memory frame in arch_timer_mem_acpi_init() initializes the loop counter with itself ('i = i'), which is suspicious in the first place and pointed out by clang. The loop condition is 'i < timer_count' and a prior for loop exits when 'i' reaches 'timer_count', therefore the second loop is never executed. Initialize the loop counter with 0 to iterate over all timers, which supposedly was the intention before the typo monster attacked. Fixes: c2743a36765d3 ("clocksource: arm_arch_timer: add GTDT support for memory-mapped timer") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
450f9689 |
|
01-Aug-2017 |
Marc Zyngier <maz@kernel.org> |
clocksource/arm_arch_timer: Use static_branch_enable_cpuslocked() Use the new static_branch_enable_cpuslocked() function to switch the workaround static key on the CPU hotplug path. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Leo Yan <leo.yan@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20170801080257.5056-5-marc.zyngier@arm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
77d62f53 |
|
26-May-2017 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
clocksource/drivers: Rename CLOCKSOURCE_ACPI_DECLARE to TIMER_ACPI_DECLARE The macro name is now renamed to 'TIMER_ACPI_DECLARE' for consistency with the CLOCKSOURCE_OF_DECLARE => TIMER_OF_DECLARE change. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
17273395 |
|
26-May-2017 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
clocksource/drivers: Rename CLOCKSOURCE_OF_DECLARE to TIMER_OF_DECLARE The CLOCKSOURCE_OF_DECLARE macro is used widely for the timers to declare the clocksource at early stage. However, this macro is also used to initialize the clockevent if any, or the clockevent only. It was originally suggested to declare another macro to initialize a clockevent, so in order to separate the two entities even they belong to the same IP. This was not accepted because of the impact on the DT where splitting a clocksource/clockevent definition does not make sense as it is a Linux concept not a hardware description. On the other side, the clocksource has not interrupt declared while the clockevent has, so it is easy from the driver to know if the description is for a clockevent or a clocksource, IOW it could be implemented at the driver level. So instead of dealing with a named clocksource macro, let's use a more generic one: TIMER_OF_DECLARE. The patch has not functional changes. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3db1200c |
|
09-Jun-2017 |
Frank Rowand <frank.rowand@sony.com> |
clocksource/drivers/arm_arch_timer: Fix read and iounmap of incorrect variable Fix boot warning 'Trying to vfree() nonexistent vm area' from arch_timer_mem_of_init(). Refactored code attempts to read and iounmap using address frame instead of address ioremap(frame->cntbase). Fixes: c389d701dfb70 ("clocksource: arm_arch_timer: split MMIO timer probing.") Signed-off-by: Frank Rowand <frank.rowand@sony.com> Reviewed-by: Fu Wei <fu.wei@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
f63d947c |
|
08-May-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
clocksource/arm_arch_timer: Fix arch_timer_mem_find_best_frame() arch_timer_mem_find_best_frame() looks through ARCH_TIMER_MEM_MAX_FRAMES frames even after finding matches to ensure the best frame is chosen, which means the variable frame will point to the last valid frame but not necessarily the best frame. On Juno, we get the following error as the wrong frame is returned as the best frame from arch_timer_mem_find_best_frame(): arch_timer: Unable to map frame @ 0x0000000000000000 arch_timer: Frame missing phys irq. Failed to initialize '/timer@2a810000': -22 Fix the issue by correctly returning the best frame from arch_timer_mem_find_best_frame(). Fixes: c389d701dfb7 ("clocksource: arm_arch_timer: split MMIO timer probing.") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1494246747-17267-1-git-send-email-sudeep.holla@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
eb645221 |
|
19-Apr-2017 |
Arnd Bergmann <arnd@arndb.de> |
arm64/arch_timer: Mark errata handlers as __maybe_unused In some rare randconfig builds, we end up with two functions being entirely unused: drivers/clocksource/arm_arch_timer.c:342:12: error: 'erratum_set_next_event_tval_phys' defined but not used [-Werror=unused-function] static int erratum_set_next_event_tval_phys(unsigned long evt, drivers/clocksource/arm_arch_timer.c:335:12: error: 'erratum_set_next_event_tval_virt' defined but not used [-Werror=unused-function] static int erratum_set_next_event_tval_virt(unsigned long evt, We could add an #ifdef around them, but we would already have to check for several symbols there and there is a chance this would get more complicated over time, so marking them as __maybe_unused is the simplest way to avoid the harmless warnings. Fixes: 01d3e3ff2608 ("arm64: arch_timer: Rework the set_next_event workarounds") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Christoffer Dall <christoffer.dall@linaro.org> Link: http://lkml.kernel.org/r/20170419173737.3846098-1-arnd@arndb.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
c2743a36 |
|
31-Mar-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: add GTDT support for memory-mapped timer The patch add memory-mapped timer register support by using the information provided by the new GTDT driver of ACPI. Signed-off-by: Fu Wei <fu.wei@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> [Mark: verify CNTFRQ, only register the first frame] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
f79d2094 |
|
31-Mar-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: simplify ACPI support code. The patch update arm_arch_timer driver to use the function provided by the new GTDT driver of ACPI. By this way, arm_arch_timer.c can be simplified, and separate all the ACPI GTDT knowledge from this timer driver. Signed-off-by: Fu Wei <fu.wei@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
c389d701 |
|
31-Mar-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: split MMIO timer probing. Currently the code to probe MMIO architected timers mixes DT parsing with actual poking of hardware. This makes the code harder than necessary to understand, and makes it difficult to add support for probing via ACPI. This patch splits the DT parsing from HW probing. The DT parsing now lives in arch_timer_mem_of_init(), which fills in an arch_timer_mem structure that it hands to probing functions that can be reused for ACPI support. Since the rate detection logic will be slight different when using ACPI, the probing is performed as a number of steps. This results in more code for the moment, and some arguably redundant work, but simplifies matters considerably when ACPI support is added. Signed-off-by: Fu Wei <fu.wei@linaro.org> [Mark: refactor the probing split] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
ca0e1b52 |
|
21-Mar-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: move arch_timer_needs_of_probing into DT init call To cleanly split code paths specific to ACPI or DT at a higher level, this patch removes arch_timer_init(), folding the relevant parts of its logic into existing callers. This pathes the way for further rework, and saves a few lines. Signed-off-by: Fu Wei <fu.wei@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
13bf6992 |
|
21-Mar-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: refactor arch_timer_needs_probing When booting with DT, it's possible for timer nodes to be probed in any order. Some common initialisation needs to occur after all nodes have been probed, and arch_timer_common_init() has code to detect when this has happened. This logic is DT-specific, and it would be best to factor it out of the common code that will be shared with ACPI. This patch folds this into the existing arch_timer_needs_probing(), which is renamed to arch_timer_needs_of_probing(), and no longer takes any arguments. This is only called when using DT, and not when using ACPI, which will have a deterministic probe order. Signed-off-by: Fu Wei <fu.wei@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
5d3dfa96 |
|
21-Mar-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: split dt-only rate handling For historical reasons, rate detection when probing via DT is somewhat convoluted. We tried to package this up in arch_timer_detect_rate(), but with the addition of ACPI worse, and gets in the way of stringent rate checking when ACPI is used. This patch makes arch_timer_detect_rate() specific to DT, ripping out ACPI logic. In preparation for rework of the MMIO timer probing, the reading of the relevant CNTFRQ register is factored out to callers. The function is then renamed to arch_timer_of_configure_rate(), which better represents its new place in the world. Comments are added in the DT and ACPI probe paths to explain this. Signed-off-by: Fu Wei <fu.wei@linaro.org> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
4502b6bb |
|
18-Jan-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: rework PPI selection Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to mean the driver will use the secure PPI *and* potentially also use the non-secure PPI. This is somewhat confusing. For arm64 it never makes sense to use the secure PPI, but we do anyway, inheriting this behaviour from 32-bit arm. For ACPI, we may not even have a valid secure PPI, so we need to be able to only request the non-secure PPI. To that end, this patch reworks the timer driver so that we can request the non-secure PPI alone. The PPI selection is split out into a new function, arch_timer_select_ppi(), and verification of the selected PPI is shifted out to callers (as DT may select the PPI by other means and must handle this anyway). We now consistently use arch_timer_has_nonsecure_ppi() to determine whether we must manage a non-secure PPI *in addition* to a secure PPI. When we only have a non-secure PPI, this returns false. Signed-off-by: Fu Wei <fu.wei@linaro.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
097cd143 |
|
18-Jan-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: add a new enum for spi type This patch add a new enum "arch_timer_spi_nr" and use it in the driver. Just for code's readability, no functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
831610c0 |
|
18-Jan-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: move enums and defines to header file To support the arm_arch_timer via ACPI we need to share defines and enums between the driver and the ACPI parser code. So we split out the relevant defines and enums into arm_arch_timer.h. No functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
ee34f1e6 |
|
18-Jan-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: rename the PPI enum In preparation for moving the PPI enum out into a header, rename the enum and its constituent values these so they are namespaced w.r.t. the arch timer. This will aid consistency and avoid potential name clashes when this move occurs. No functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
8a5c21dc |
|
18-Jan-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: rename type macros In preparation for moving the type macros out into a header, rename these so they are namespaced w.r.t. the arch timer. We'll apply the same prefix to other definitions in subsequent patches. This will aid consistency and avoid potential name clahses when this move occurs. No functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
ded24019 |
|
18-Jan-2017 |
Fu Wei <fu.wei@linaro.org> |
clocksource: arm_arch_timer: clean up printk usage Almost all string in the arm_arch_timer driver duplicate an common prefix (though a few do not). For consistency, it would be better to use pr_fmt(), and always use this prefix. At the same time, we may as well clean up some whitespace issues in arch_timer_banner and arch_timer_init. No functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
|
#
ac9ce6d1 |
|
09-Mar-2017 |
Rafał Miłecki <rafal@milecki.pl> |
clocksource: Add missing line break to error messages Printing with pr_* functions requires adding line break manually. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
d003d029 |
|
21-Feb-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Add HISILICON_ERRATUM_161010101 ACPI matching data In order to deal with ACPI enabled platforms suffering from the HISILICON_ERRATUM_161010101, let's add the required OEM data that allow the workaround to be enabled. Acked-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: dann frazier <dann.frazier@canonical.com> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
5a38bcac |
|
21-Feb-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Allow erratum matching with ACPI OEM information Just as we're able to identify a broken platform using some DT information, let's enable a way to spot the offenders with ACPI. The difference is that we can only match on some OEM info instead of implementation-specific properties. So in order to avoid the insane multiplication of errata structures, we allow an array of OEM descriptions to be attached to an erratum structure. Acked-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: dann frazier <dann.frazier@canonical.com> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
fa8d815f |
|
26-Jan-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Workaround for Cortex-A73 erratum 858921 Cortex-A73 (all versions) counter read can return a wrong value when the counter crosses a 32bit boundary. The workaround involves performing the read twice, and to return one or the other depending on whether a transition has taken place. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
a86bd139 |
|
31-Jan-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled Userspace being allowed to use read CNTVCT_EL0 anytime (and not only in the VDSO), we need to enable trapping whenever a cntvct workaround is enabled on a given CPU. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
bee67c53 |
|
04-Apr-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Save cntkctl_el1 as a per-cpu variable As we're about to allow per CPU cntkctl_el1 configuration, we cannot rely on the register value to be common when performing power management. Let's turn saved_cntkctl into a per-cpu variable. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
992dd16f |
|
01-Feb-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Move clocksource_counter and co around In order to access clocksource_counter from the errata handling code, move it (together with the related structures and functions) towards the top of the file. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
6acc71cc |
|
20-Feb-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUs Instead of applying a CPU-specific workaround to all CPUs in the system, allow it to only affect a subset of them (typical big-little case). This is done by turning the erratum pointer into a per-CPU variable. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
01d3e3ff |
|
27-Jan-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Rework the set_next_event workarounds The way we work around errata affecting set_next_event is not very nice, at it imposes this workaround on errata that do not need it. Add new workaround hooks and let the existing workarounds use them. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
8328089f |
|
27-Jan-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Get rid of erratum_workaround_set_sne Let's move the handling of workarounds affecting set_next_event to the affected function, instead of overriding the pointers as an afterthough. Yes, this is an extra indirection on the erratum handling path, but the HW is busted anyway. This will allow for some more flexibility later. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
f4e00a1a |
|
20-Jan-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Move arch_timer_reg_read/write around As we're about to move things around, let's start with the low level read/write functions. This allows us to use these functions in the errata handling code without having to use forward declaration of static functions. Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
0064030c |
|
20-Mar-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Add erratum handler for CPU-specific capability Should we ever have a workaround for an erratum that is detected using a capability and affecting a particular CPU, it'd be nice to have a way to probe them directly. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
651bb2e9 |
|
19-Jan-2017 |
Marc Zyngier <maz@kernel.org> |
arm64: arch_timer: Add infrastructure for multiple erratum detection methods We're currently stuck with DT when it comes to handling errata, which is pretty restrictive. In order to make things more flexible, let's introduce an infrastructure that could support alternative discovery methods. No change in functionality. Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
e6017571 |
|
01-Feb-2017 |
Ingo Molnar <mingo@kernel.org> |
sched/headers: Prepare for new header dependencies before moving code to <linux/sched/clock.h> We are going to split <linux/sched/clock.h> out of <linux/sched.h>, which will have to be picked up from other headers and .c files. Create a trivial placeholder <linux/sched/clock.h> file that just maps to <linux/sched.h> to make this patch obviously correct and bisectable. Include the new header in the files that are going to need it. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
3d837bc0 |
|
11-Feb-2017 |
Bhumika Goyal <bhumirks@gmail.com> |
clocksource/drivers/arm_arch_timer:: Mark cyclecounter __ro_after_init The object cyclecounter of type cyclecounter is only modified during initialization in arch_counter_register. So it can be marked __ro_after_init. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Cc: mark.rutland@arm.com Cc: keescook@chromium.org Cc: marc.zyngier@arm.com Cc: daniel.lezcano@linaro.org Cc: julia.lawall@lip6.fr Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1486840818-22214-1-git-send-email-bhumirks@gmail.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
bb42ca47 |
|
06-Feb-2017 |
Ding Tianhong <dingtianhong@huawei.com> |
clocksource/drivers/arm_arch_timer: Work around Hisilicon erratum 161010101 Erratum Hisilicon-161010101 says that the ARM generic timer counter "has the potential to contain an erroneous value when the timer value changes". Accesses to TVAL (both read and write) are also affected due to the implicit counter read. Accesses to CVAL are not affected. The workaround is to reread the system count registers until the value of the second read is larger than the first one by less than 32, the system counter can be guaranteed not to return wrong value twice by back-to-back read and the error value is always larger than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> [Mark: split patch, fix Kconfig, reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
16d10ef2 |
|
06-Feb-2017 |
Ding Tianhong <dingtianhong@huawei.com> |
clocksource/drivers/arm_arch_timer: Introduce generic errata handling infrastructure Currently we have code inline in the arch timer probe path to cater for Freescale erratum A-008585, complete with ifdeffery. This is a little ugly, and will get worse as we try to add more errata handling. This patch refactors the handling of Freescale erratum A-008585. Now the erratum is described in a generic arch_timer_erratum_workaround structure, and the probe path can iterate over these to detect errata and enable workarounds. This will simplify the addition and maintenance of code handling Hisilicon erratum 161010101. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> [Mark: split patch, correct Kconfig, reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
5444ea6a |
|
06-Feb-2017 |
Ding Tianhong <dingtianhong@huawei.com> |
clocksource/drivers/arm_arch_timer: Remove fsl-a008585 parameter Having a command line option to flip the errata handling for a particular erratum is a little bit unusual, and it's vastly superior to pass this in the DT. By common consensus, it's best to kill off the command line parameter. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> [Mark: split patch, reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
a5a1d1c2 |
|
21-Dec-2016 |
Thomas Gleixner <tglx@linutronix.de> |
clocksource: Use a plain u64 instead of cycle_t There is no point in having an extra type for extra confusion. u64 is unambiguous. Conversion was done with the following coccinelle script: @rem@ @@ -typedef u64 cycle_t; @fix@ typedef cycle_t; @@ -cycle_t +u64 Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: John Stultz <john.stultz@linaro.org>
|
#
73c1b41e |
|
21-Dec-2016 |
Thomas Gleixner <tglx@linutronix.de> |
cpu/hotplug: Cleanup state names When the state names got added a script was used to add the extra argument to the calls. The script basically converted the state constant to a string, but the cleanup to convert these strings into meaningful ones did not happen. Replace all the useless strings with 'subsys/xxx/yyy:state' strings which are used in all the other places already. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sebastian Siewior <bigeasy@linutronix.de> Link: http://lkml.kernel.org/r/20161221192112.085444152@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
f947ee14 |
|
26-Oct-2016 |
Stephen Boyd <sboyd@codeaurora.org> |
clocksource/drivers/arm_arch_timer: Map frame with of_io_request_and_map() Let's use the of_io_request_and_map() API so that the frame region is protected and shows up in /proc/iomem. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
d8ec7595 |
|
04-Oct-2016 |
Brian Norris <briannorris@chromium.org> |
clocksource/drivers/arm_arch_timer: Don't assume clock runs in suspend The ARM specifies that the system counter "must be implemented in an always-on power domain," and so we try to use the counter as a source of timekeeping across suspend/resume. Unfortunately, some SoCs (e.g., Rockchip's RK3399) do not keep the counter ticking properly when switched from their high-power clock to the lower-power clock used in system suspend. Support this quirk by adding a new device tree property. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
1d8f51d4 |
|
22-Sep-2016 |
Scott Wood <oss@buserror.net> |
arm/arm64: arch_timer: Use archdata to indicate vdso suitability Instead of comparing the name to a magic string, use archdata to explicitly communicate whether the arch timer is suitable for direct vdso access. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Scott Wood <oss@buserror.net> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
f6dc1576 |
|
22-Sep-2016 |
Scott Wood <oss@buserror.net> |
arm64: arch_timer: Work around QorIQ Erratum A-008585 Erratum A-008585 says that the ARM generic timer counter "has the potential to contain an erroneous value for a small number of core clock cycles every time the timer value changes". Accesses to TVAL (both read and write) are also affected due to the implicit counter read. Accesses to CVAL are not affected. The workaround is to reread TVAL and count registers until successive reads return the same value. Writes to TVAL are replaced with an equivalent write to CVAL. The workaround is to reread TVAL and count registers until successive reads return the same value, and when writing TVAL to retry until counter reads before and after the write return the same value. The workaround is enabled if the fsl,erratum-a008585 property is found in the timer node in the device tree. This can be overridden with the clocksource.arm_arch_timer.fsl-a008585 boot parameter, which allows KVM users to enable the workaround until a mechanism is implemented to automatically communicate this information. This erratum can be found on LS1043A and LS2080A. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Scott Wood <oss@buserror.net> [will: renamed read macro to reflect that it's not usually unstable] Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
f005bd7e |
|
01-Aug-2016 |
Marc Zyngier <maz@kernel.org> |
clocksource/arm_arch_timer: Force per-CPU interrupt to be level-triggered The ARM architected timer produces level-triggered interrupts (this is mandated by the architecture). Unfortunately, a number of device-trees get this wrong, and expose an edge-triggered interrupt. Until now, this wasn't too much an issue, as the programming of the trigger would fail (the corresponding PPI cannot be reconfigured), and the kernel would be happy with this. But we're about to change this, and trust DT a lot if the driver doesn't provide its own trigger information. In that context, the timer breaks badly. While we do need to fix the DTs, there is also some userspace out there (kvmtool) that generates the same kind of broken DT on the fly, and that will completely break with newer kernels. As a safety measure, and to keep buggy software alive as well as buying us some time to fix DTs all over the place, let's check what trigger configuration has been given us by the firmware. If this is not a level configuration, then we know that the DT/ACPI configuration is bust, and we pick some defaults which won't be worse than the existing setup. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Liu Gang <Gang.Liu@nxp.com> Cc: Mark Rutland <marc.rutland@arm.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Wenbin Song <Wenbin.Song@freescale.com> Cc: Mingkai Hu <Mingkai.Hu@freescale.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Jon Hunter <jonathanh@nvidia.com> Cc: arm@kernel.org Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-arm-kernel@lists.infradead.org Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Ray Jui <rjui@broadcom.com> Cc: "Hou Zhiqiang" <B48286@freescale.com> Cc: Tirumalesh Chalamarla <tchalamarla@cavium.com> Cc: linux-samsung-soc@vger.kernel.org Cc: Yuan Yao <yao.yuan@nxp.com> Cc: Jan Glauber <jglauber@cavium.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: linux-amlogic@lists.infradead.org Cc: soren.brinkmann@xilinx.com Cc: Rajesh Bhagat <rajesh.bhagat@freescale.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Duc Dang <dhdang@apm.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Carlo Caione <carlo@caione.org> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Link: http://lkml.kernel.org/r/1470045256-9032-2-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
7e86e8bd |
|
13-Jul-2016 |
Richard Cochran <rcochran@linutronix.de> |
clocksource/arm_arch_timer: Convert to hotplug state machine Install the callbacks via the state machine and let the core invoke the callbacks on the already online CPUs. Signed-off-by: Richard Cochran <rcochran@linutronix.de> Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: rt@linutronix.de Link: http://lkml.kernel.org/r/20160713153336.048259040@linutronix.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
46fd5c6b |
|
27-Jun-2016 |
Will Deacon <will@kernel.org> |
clocksource/drivers/arm_arch_timer: Control the evtstrm via the cmdline Disabling the eventstream can be useful for both remotely debugging a deployed production system and development of code using WFE-based polling loops. Whilst this can currently be controlled via a Kconfig option (CONFIG_ARM_ARCH_TIMER_EVTSTREAM), it's often desirable to toggle the feature on the command line, so this patch adds a new command-line option ("clocksource.arm_arch_timer.evtstrm") to do just that. The default behaviour is determined based on CONFIG_ARM_ARCH_TIMER_EVTSTREAM. Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
177cf6e5 |
|
06-Jun-2016 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
clocksources: Switch back to the clksrc table All the clocksource drivers's init function are now converted to return an error code. CLOCKSOURCE_OF_DECLARE is no longer used as well as the clksrc-of table. Let's convert back the names: - CLOCKSOURCE_OF_DECLARE_RET => CLOCKSOURCE_OF_DECLARE - clksrc-of-ret => clksrc-of Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> For exynos_mct and samsung_pwm_timer: Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> For arch/arc: Acked-by: Vineet Gupta <vgupta@synopsys.com> For mediatek driver: Acked-by: Matthias Brugger <matthias.bgg@gmail.com> For the Rockchip-part Acked-by: Heiko Stuebner <heiko@sntech.de> For STi : Acked-by: Patrice Chotard <patrice.chotard@st.com> For the mps2-timer.c and versatile.c changes: Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> For the OXNAS part : Acked-by: Neil Armstrong <narmstrong@baylibre.com> For LPC32xx driver: Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com> For Broadcom Kona timer change: Acked-by: Ray Jui <ray.jui@broadcom.com> For Sun4i and Sun5i: Acked-by: Chen-Yu Tsai <wens@csie.org> For Meson6: Acked-by: Carlo Caione <carlo@caione.org> For Keystone: Acked-by: Santosh Shilimkar <ssantosh@kernel.org> For NPS: Acked-by: Noam Camus <noamca@mellanox.com> For bcm2835: Acked-by: Eric Anholt <eric@anholt.net>
|
#
3c0731db |
|
06-Jun-2016 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
clocksource/drivers/arm_arch_timer: Convert init function to return error The init functions do not return any error. They behave as the following: - panic, thus leading to a kernel crash while another timer may work and make the system boot up correctly or - print an error and let the caller unaware if the state of the system Change that by converting the init functions to return an error conforming to the CLOCKSOURCE_OF_RET prototype. Proper error handling (rollback, errno value) will be changed later case by case, thus this change just return back an error or success in the init function. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
a53d892d |
|
11-Apr-2016 |
Julien Grall <julien.grall@arm.com> |
clocksource: arm_arch_timer: Remove arch_timer_get_timecounter The only call of arch_timer_get_timecounter (in KVM) has been removed. Signed-off-by: Julien Grall <julien.grall@arm.com> Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
#
d9b5e415 |
|
11-Apr-2016 |
Julien Grall <julien.grall@arm.com> |
clocksource: arm_arch_timer: Extend arch_timer_kvm_info to get the virtual IRQ Currently, the firmware table is parsed by the virtual timer code in order to retrieve the virtual timer interrupt. However, this is already done by the arch timer driver. To avoid code duplication, extend arch_timer_kvm_info to get the virtual IRQ. Note that the KVM code will be modified in a subsequent patch. Signed-off-by: Julien Grall <julien.grall@arm.com> Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
#
b4d6ce97 |
|
11-Apr-2016 |
Julien Grall <julien.grall@arm.com> |
clocksource: arm_arch_timer: Gather KVM specific information in a structure Introduce a structure which are filled up by the arch timer driver and used by the virtual timer in KVM. The first member of this structure will be the timecounter. More members will be added later. A stub for the new helper isn't introduced because KVM requires the arch timer for both ARM64 and ARM32. The function arch_timer_get_timecounter is kept for the time being and will be dropped in a subsequent patch. Signed-off-by: Julien Grall <julien.grall@arm.com> Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
|
#
f81f03fa |
|
20-Feb-2014 |
Marc Zyngier <maz@kernel.org> |
arm64: Allow the arch timer to use the HYP timer With the ARMv8.1 VHE, the kernel can run in HYP mode, and thus use the HYP timer instead of the normal guest timer in a mostly transparent way, except for the interrupt line. This patch reworks the arch timer code to allow the selection of the HYP PPI, possibly falling back to the guest timer if not available. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
#
cf8c5009 |
|
23-Dec-2015 |
Viresh Kumar <viresh.kumar@linaro.org> |
clockevents/drivers/arm_arch_timer: Implement ->set_state_oneshot_stopped() set_state_oneshot_stopped() is called by the clkevt core, when the next event is required at an expiry time of 'KTIME_MAX'. This normally happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes. This patch makes the clockevent device to stop on such an event, to avoid spurious interrupts, as explained by: commit 8fff52fd5093 ("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state"). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
e392d603 |
|
31-Jan-2016 |
Robin Murphy <robin.murphy@arm.com> |
clocksource/drivers/arm_arch_timer: Enable and verify MMIO access So far, we have been blindly assuming that having access to a memory-mapped timer frame implies that the individual elements of that frame frame are already enabled. Whilst it's the firmware's job to give us non-secure access to frames in the first place, we should not rely on implementations always being generous enough to also configure CNTACR for those non-secure frames (e.g. [1]). Explicitly enable feature-level access per-frame, and verify that the access we want is really implemented before trying to make use of it. [1]:https://github.com/ARM-software/tf-issues/issues/170 Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Tested-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
ae281cbd |
|
28-Sep-2015 |
Marc Zyngier <maz@kernel.org> |
clocksource / arm_arch_timer: Convert to ACPI probing It is now absolutely trivial to convert the arch timer driver to use ACPI probing, just like its DT counterpart. Let's enjoy another crapectomy. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
46c5bfdd |
|
12-Jun-2015 |
Viresh Kumar <viresh.kumar@linaro.org> |
clockevents/drivers/arm_arch_timer: Migrate to new 'set-state' interface Migrate arm_arch_timer driver to the new 'set-state' interface provided by the clockevents core, the earlier 'set-mode' interface is marked obsolete now. This also enables us to implement callbacks for new states of clockevent devices, for example: ONESHOT_STOPPED. Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
566e6dfa |
|
30-Mar-2015 |
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> |
clocksource/drivers/arm_arch_timer: Rename 'arch_timer_probed()' to 'arch_timer_needs_probing()' to reflect behaviour The arch_timer_probed() function returns whether the given time doesn't need to be probed. This can be the case when the timer has been probed already, but also when it has no corresponding enabled node in DT. Rename the function to arch_timer_needs_probing() and invert its return value to better reflect the function's purpose and behaviour. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1427796746-373-1-git-send-email-daniel.lezcano@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
b09ca1ec |
|
24-Mar-2015 |
Hanjun Guo <guohanjun@huawei.com> |
clocksource / arch_timer: Parse GTDT to initialize arch timer Using the information presented by GTDT (Generic Timer Description Table) to initialize the arch timer (not memory-mapped). CC: Daniel Lezcano <daniel.lezcano@linaro.org> CC: Thomas Gleixner <tglx@linutronix.de> Originally-by: Amit Daniel Kachhap <amit.daniel@samsung.com> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Tested-by: Yijing Wang <wangyijing@huawei.com> Tested-by: Mark Langsdorf <mlangsdo@redhat.com> Tested-by: Jon Masters <jcm@redhat.com> Tested-by: Timur Tabi <timur@codeaurora.org> Tested-by: Robert Richter <rrichter@cavium.com> Acked-by: Robert Richter <rrichter@cavium.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
|
#
7c8f1e78 |
|
06-Jan-2015 |
Richard Cochran <richardcochran@gmail.com> |
arm_arch_timer: include clocksource.h directly This driver makes use of the clocksource code. Previously it had only included the proper header indirectly, but that chain was inadvertently broken by 74d23cc "time: move the timecounter/cyclecounter code into its own file." This patch fixes the issue by including clocksource.h directly. Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
d6ad3691 |
|
10-Dec-2014 |
Catalin Marinas <catalin.marinas@arm.com> |
clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64 Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical timers when requested) introduces the use of physical counters in the ARM architected timer driver. However, he arm64 kernel uses CNTVCT in VDSO. When booting in EL2, the kernel switches to the physical timers to make things easier for KVM but it continues to use the virtual counter both in user and kernel. While in such scenario CNTVCT == CNTPCT (since CNTVOFF is initialised by the kernel to 0), we want to spot firmware bugs corrupting CNTVOFF early (which would affect CNTVCT). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Yingjoe Chen <yingjoe.chen@mediatek.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
#
65b5732d |
|
08-Oct-2014 |
Doug Anderson <dianders@chromium.org> |
clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers Some 32-bit (ARMv7) systems are architected like this: * The firmware doesn't know and doesn't care about hypervisor mode and we don't want to add the complexity of hypervisor there. * The firmware isn't involved in SMP bringup or resume. * The ARCH timer come up with an uninitialized offset (CNTVOFF) between the virtual and physical counters. Each core gets a different random offset. * The device boots in "Secure SVC" mode. * Nothing has touched the reset value of CNTHCTL.PL1PCEN or CNTHCTL.PL1PCTEN (both default to 1 at reset) On systems like the above, it doesn't make sense to use the virtual counter. There's nobody managing the offset and each time a core goes down and comes back up it will get reinitialized to some other random value. This adds an optional property which can inform the kernel of this situation, and firmware is free to remove the property if it is going to initialize the CNTVOFF registers when each CPU comes out of reset. Currently, the best course of action in this case is to use the physical timer, which is why it is important that CNTHCTL hasn't been changed from its reset value and it's a reasonable assumption given that the firmware has never entered HYP mode. Note that it's been said that on ARMv8 systems the firmware and kernel really can't be architected as described above. That means using the physical timer like this really only makes sense for ARMv7 systems. Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
|
#
0b46b8a7 |
|
24-Nov-2014 |
Sonny Rao <sonnyrao@chromium.org> |
clocksource: arch_timer: Fix code to use physical timers when requested This is a bug fix for using physical arch timers when the arch_timer_use_virtual boolean is false. It restores the arch_counter_get_cntpct() function after removal in 0d651e4e "clocksource: arch_timer: use virtual counters" We need this on certain ARMv7 systems which are architected like this: * The firmware doesn't know and doesn't care about hypervisor mode and we don't want to add the complexity of hypervisor there. * The firmware isn't involved in SMP bringup or resume. * The ARCH timer come up with an uninitialized offset between the virtual and physical counters. Each core gets a different random offset. * The device boots in "Secure SVC" mode. * Nothing has touched the reset value of CNTHCTL.PL1PCEN or CNTHCTL.PL1PCTEN (both default to 1 at reset) One example of such as system is RK3288 where it is much simpler to use the physical counter since there's nobody managing the offset and each time a core goes down and comes back up it will get reinitialized to some other random value. Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters") Cc: stable@vger.kernel.org Signed-off-by: Sonny Rao <sonnyrao@chromium.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
|
#
59aa896d |
|
15-Oct-2014 |
Marc Zyngier <maz@kernel.org> |
ARM/ARM64: arch-timer: fix arch_timer_probed logic Commit c387f07e6205 (clocksource: arm_arch_timer: Discard unavailable timers correctly) changed the way the driver makes sure both the memory and system-register timers have been probed before finalizing the probing. There is a interesting flaw in this logic that leads to this final step never to be executed. Things seems to work pretty well until something actually needs the data that is produced during this final stage. For example, KVM explodes on the first run of a guest when executed on a platform that has both memory and sysreg nodes (Juno, for example). Just fix the damned logic, and enjoy booting VMs again. Tested on a Juno system. Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Christoffer Dall <christoffer.dall@linaro.org> Reported-by: Riku Voipio <riku.voipio@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
e1ce5c7a |
|
28-Sep-2014 |
Nathan Lynch <nathan_lynch@mentor.com> |
clocksource: arm_arch_timer: Consolidate arch_timer_evtstrm_enable The arch_timer_evtstrm_enable hooks in arm and arm64 are substantially similar, the only difference being a CONFIG_COMPAT-conditional section which is relevant only for arm64. Copy the arm64 version to the driver, removing the arch-specific hooks. Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com>
|
#
8b8dde00 |
|
28-Sep-2014 |
Nathan Lynch <nathan_lynch@mentor.com> |
clocksource: arm_arch_timer: Enable counter access for 32-bit ARM The only difference between arm and arm64's implementations of arch_counter_set_user_access is that 32-bit ARM does not enable user access to the virtual counter. We want to enable this access for the 32-bit ARM VDSO, so copy the arm64 version to the driver itself, and remove the arch-specific implementations. Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com>
|
#
423bd69e |
|
28-Sep-2014 |
Nathan Lynch <nathan_lynch@mentor.com> |
clocksource: arm_arch_timer: Change clocksource name if CP15 unavailable The arm and arm64 VDSOs need CP15 access to the architected counter. If this is unavailable (which is allowed by ARM v7), indicate this by changing the clocksource name to "arch_mem_counter" before registering the clocksource. Suggested by Stephen Boyd. Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com>
|
#
c387f07e |
|
28-Sep-2014 |
Sudeep Holla <sudeep.holla@arm.com> |
clocksource: arm_arch_timer: Discard unavailable timers correctly Currently we wait until both cp15 and mem timers are probed if we have both timer device nodes present in the device tree without checking if the device is actually available. If one of the timer device node present is disabled, the system locks up on the boot as no timer gets registered. This patch adds the check for the availability of the timer device so that unavailable timers are discarded correctly. It also adds the missing of_node_put. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
82a56194 |
|
08-Apr-2014 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue ARM arch timers are tightly coupled with the CPU logic and lose context on platform implementing HW power management when cores are powered down at run-time. Marking the arch timers as C3STOP regardless of power management capabilities causes issues on platforms with no power management, since in that case the arch timers cannot possibly enter states where the timer loses context at runtime and therefore can always be used as a high resolution clockevent device. In order to fix the C3STOP issue in a way compliant with how real HW works, this patch adds a boolean property to the arch timer bindings to define if the arch timer is managed by an always-on power domain. This power domain is present on all ARM platforms to date, and manages HW that must not be turned off, whatever the state of other HW components (eg power controller). On platforms with no power management capabilities, it is the only power domain present, which encompasses and manages power supply for all HW components in the system. If the timer is powered by the always-on power domain, the always-on property must be present in the bindings which means that the timer cannot be shutdown at runtime, so it is not a C3STOP clockevent device. If the timer binding does not contain the always-on property, the timer is assumed to be power-gateable, hence it must be defined as a C3STOP clockevent device. Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Magnus Damm <damm@opensource.se> Cc: Marc Carino <marc.ceeeee@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
7b52ad2e |
|
06-Jan-2014 |
Stephen Boyd <sboyd@codeaurora.org> |
clocksource: arch_timer: Set dynamic irq affinity on mmio clockevent Set the CLOCK_EVT_FEAT_DYNIRQ flag on the memory mapped clockevent so that we save power by waking up the CPU with the next event when this timer is used in broadcast mode. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
4a7d3e8a |
|
15-Oct-2013 |
Thierry Reding <thierry.reding@gmail.com> |
clocksource: arch_timer: Do not register arch_sys_counter twice Commit: 65cd4f6 ("arch_timer: Move to generic sched_clock framework") added code to register the arch_sys_counter in arch_timer_register(), but it is already registered in arch_counter_register(). This results in the timer being added to the clocksource list twice, therefore causing an infinite loop in the list. Remove the duplicate registration and register the scheduler clock after the original registration instead. This fixes a hang during boot on Tegra114 (Cortex-A15). [ While I've only tested this on Tegra114, I suspect the same hang during boot happens for all processors that use this clock source. ] Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: John Stultz <john.stultz@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: linux-arm-kernel@lists.infradead.org Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Link: http://lkml.kernel.org/r/1381843911-31962-1-git-send-email-treding@nvidia.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
65cd4f6c |
|
18-Jul-2013 |
Stephen Boyd <sboyd@codeaurora.org> |
arch_timer: Move to generic sched_clock framework Register with the generic sched_clock framework now that it supports 64 bits. This fixes two problems with the current sched_clock support for machines using the architected timers. First off, we don't subtract the start value from subsequent sched_clock calls so we can potentially start off with sched_clock returning gigantic numbers. Second, there is no support for suspend/resume handling so problems such as discussed in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during suspend, 2012-10-23) can happen without this patch. Finally, it allows us to move the sched_clock setup into drivers clocksource out of the arch ports. Cc: Christopher Covington <cov@codeaurora.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: John Stultz <john.stultz@linaro.org>
|
#
4fbcdc81 |
|
27-Sep-2013 |
Stephen Boyd <sboyd@codeaurora.org> |
clocksource: arm_arch_timer: Use clocksource for suspend timekeeping The ARM architected timers keep counting during suspend so we can mark this clocksource with the CLOCK_SOURCE_SUSPEND_NONSTOP flag. This flag will indicate that this clocksource can be used for calculating suspend time and injecting sleep time into the timekeeping core. This should be more accurate than using an external RTC or architecture specific persistent clock. Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
#
346e7480 |
|
23-Aug-2013 |
Sudeep Holla <sudeep.holla@arm.com> |
drivers: clocksource: add CPU PM notifier for ARM architected timer Few control settings done in architected timer as part of initialisation can be lost when CPU enters deeper power states. They need to be restored when the CPU is (warm)reset again. This patch adds CPU PM notifiers to save the counter control register when entering low power modes and restore it when CPU exits low power. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Will Deacon <will.deacon@arm.com> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
|
#
037f6377 |
|
23-Aug-2013 |
Will Deacon <will@kernel.org> |
drivers: clocksource: add support for ARM architected timer event stream The ARM architected timer can generate events (used for waking up CPUs executing the wfe instruction) at a frequency represented as a power-of-2 divisor of the clock rate. An event stream might be used: - To implement wfe-based timeouts for userspace locking implementations. - To impose a timeout on a wfe for safeguarding against any programming error in case an expected event is not generated. This patch computes the event stream frequency aiming for a period of 100us between events. It uses ARM/ARM64 specific backends to configure and enable the event stream. Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Will Deacon <will.deacon@arm.com> [sudeep: moving ARM/ARM64 changes into separate patches and adding Kconfig option] Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
|
#
22006994 |
|
18-Jul-2013 |
Stephen Boyd <sboyd@codeaurora.org> |
clocksource: arch_timer: Add support for memory mapped timers Add support for the memory mapped timers by filling in the read/write functions and adding some parsing code. Note that we only register one clocksource, preferring the cp15 based clocksource over the mmio one. To keep things simple we register one global clockevent. This covers the case of UP and SMP systems with only mmio hardware and systems where the memory mapped timers are used as the broadcast timer in low power modes. The DT binding allows for per-CPU memory mapped timers in case we want to support that in the future, but the code isn't added here. We also don't do much for hypervisor support, although it should be possible to support it by searching for at least two frames where one frame has the virtual capability and then updating KVM timers to support it. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <Marc.Zyngier@arm.com> Cc: Rob Herring <robherring2@gmail.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
|
#
60faddf6 |
|
18-Jul-2013 |
Stephen Boyd <sboyd@codeaurora.org> |
clocksource: arch_timer: Push the read/write wrappers deeper We're going to introduce support to read and write the memory mapped timer registers in the next patch, so push the cp15 read/write functions one level deeper. This simplifies the next patch and makes it clearer what's going on. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <Marc.Zyngier@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
|
#
1ff99ea6 |
|
18-Jul-2013 |
Stephen Boyd <sboyd@codeaurora.org> |
clocksource: arch_timer: Pass clock event to set_mode callback There isn't any reason why we don't pass the event here and we'll need it in the near future for memory mapped arch timers anyway. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <Marc.Zyngier@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
|
#
e09f3cc0 |
|
18-Jul-2013 |
Stephen Boyd <sboyd@codeaurora.org> |
clocksource: arch_timer: Make register accessors less error-prone Using an enum for the register we wish to access allows newer compilers to determine if we've forgotten a case in our switch statement. This allows us to remove the BUILD_BUG() instances in the arm64 port, avoiding problems where optimizations may not happen. To try and force better code generation we're currently marking the accessor functions as inline, but newer compilers can ignore the inline keyword unless it's marked __always_inline. Luckily on arm and arm64 inline is __always_inline, but let's make everything __always_inline to be explicit. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <Marc.Zyngier@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
|
#
8c37bb3a |
|
19-Jun-2013 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
clocksource+irqchip: delete __cpuinit usage from all related files The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/clocksource and drivers/irqchip uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
#
0d651e4e |
|
30-Jan-2013 |
Mark Rutland <mark.rutland@arm.com> |
clocksource: arch_timer: use virtual counters Switching between reading the virtual or physical counters is problematic, as some core code wants a view of time before we're fully set up. Using a function pointer and switching the source after the first read can make time appear to go backwards, and having a check in the read function is an unfortunate block on what we want to be a fast path. Instead, this patch makes us always use the virtual counters. If we're a guest, or don't have hyp mode, we'll use the virtual timers, and as such don't care about CNTVOFF as long as it doesn't change in such a way as to make time appear to travel backwards. As the guest will use the virtual timers, a (potential) KVM host must use the physical timers (which can wake up the host even if they fire while a guest is executing), and hence a host must have CNTVOFF set to zero so as to have a consistent view of time between the physical timers and virtual counters. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Rob Herring <rob.herring@calxeda.com>
|
#
f31c2f1c |
|
17-Apr-2013 |
Stephen Boyd <sboyd@codeaurora.org> |
ARM: arch_timer: Silence debug preempt warnings Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm architected timers causes a slew of "using smp_processor_id() in preemptible" warnings: BUG: using smp_processor_id() in preemptible [00000000] code: sh/111 caller is arch_timer_cpu_notify+0x14/0xc8 This happens because sometimes the cpu notifier, arch_timer_cpu_notify(), is called in preemptible context and other times in non-preemptible context but we use this_cpu_ptr() to retrieve the clockevent in all cases. We're only going to actually use the pointer in non-preemptible context though, so push the this_cpu_ptr() access down into the cases to force the checks to occur only in non-preemptible contexts. Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <Marc.Zyngier@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Olof Johansson <olof@lixom.net>
|
#
0583fe47 |
|
10-Apr-2013 |
Rob Herring <rob.herring@calxeda.com> |
ARM: convert arm/arm64 arch timer to use CLKSRC_OF init This converts arm and arm64 to use CLKSRC_OF DT based initialization for the arch timer. A new function arch_timer_arch_init is added to allow for arch specific setup. This has a side effect of enabling sched_clock on omap5 and exynos5. There should not be any reason not to use the arch timers for sched_clock. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Simon Horman <horms@verge.net.au> Cc: Magnus Damm <magnus.damm@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-samsung-soc@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-sh@vger.kernel.org Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
#
8266891e |
|
10-Jan-2013 |
Marc Zyngier <maz@kernel.org> |
ARM: arch_timers: switch to physical timers if HYP mode is available If we're booted in HYP mode, it is possible that we'll run some kind of virtualized environment. In this case, it is a better to switch to the physical timers, and leave the virtual timers to guests. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
1aee5d7a |
|
20-Nov-2012 |
Mark Rutland <mark.rutland@arm.com> |
arm64: move from arm_generic to arm_arch_timer The arch_timer driver supports a superset of the functionality of the arm_generic driver, and is not tied to a particular arch. This patch moves arm64 to use the arch_timer driver, gaining additional functionality in doing so, and removes the (now unused) arm_generic driver. Timer-related hooks specific to arm64 are moved into arch/arm64/kernel/time.c. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
#
8a4da6e3 |
|
12-Nov-2012 |
Mark Rutland <mark.rutland@arm.com> |
arm: arch_timer: move core to drivers/clocksource The core functionality of the arch_timer driver is not directly tied to anything under arch/arm, and can be split out. This patch factors out the core of the arch_timer driver, so it can be shared with other architectures. A couple of functions are added so that architecture-specific code can interact with the driver without needing to touch its internals. The ARM_ARCH_TIMER config variable is moved out to drivers/clocksource/Kconfig, existing uses in arch/arm are replaced with HAVE_ARM_ARCH_TIMER, which selects it. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
|