An error occurred fetching the project authors.
- 05 Dec, 2020 1 commit
-
-
Keqian Zhu authored
In commit 0ea41539 ("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: 0ea41539 ("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
-
- 08 Jul, 2020 2 commits
-
-
Marc Zyngier authored
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.orgSigned-off-by:
Will Deacon <will@kernel.org>
-
Marc Zyngier authored
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.orgSigned-off-by:
Will Deacon <will@kernel.org>
-
- 22 May, 2020 1 commit
-
-
Dejin Zheng authored
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
-
- 06 Mar, 2020 1 commit
-
-
Ionela Voinescu authored
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>
-
- 25 Feb, 2020 1 commit
-
-
Vincenzo Frascino authored
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: 5e3c6a31 ("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
-
- 17 Feb, 2020 1 commit
-
-
Thomas Gleixner authored
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
-
- 25 Jun, 2019 1 commit
-
-
Andrew Murray authored
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>
-
- 19 Jun, 2019 1 commit
-
-
Thomas Gleixner authored
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.deSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 12 Jun, 2019 1 commit
-
-
Julien Thierry authored
With v5.2-rc1, The ftrace functions_graph tracer locks up whenever it is enabled on arm64. Since commit 0ea41539 ("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: 0ea41539 ("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>
-
- 30 Apr, 2019 4 commits
-
-
Marc Zyngier authored
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>
-
Marc Zyngier authored
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>
-
Marc Zyngier authored
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>
-
Marc Zyngier authored
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>
-
- 16 Apr, 2019 1 commit
-
-
Andrew Murray authored
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>
-
- 11 Apr, 2019 1 commit
-
-
Yangtao Li authored
After this commit ded24019(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>
-
- 23 Feb, 2019 1 commit
-
-
Samuel Holland authored
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#L272Acked-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>
-
- 19 Feb, 2019 1 commit
-
-
Andre Przywara authored
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>
-
- 01 Oct, 2018 1 commit
-
-
Marc Zyngier authored
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>
-
- 02 Aug, 2018 1 commit
-
-
Thomas Gleixner authored
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>
-
- 10 Jul, 2018 1 commit
-
-
Sudeep Holla authored
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 1332a905 ("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
-
- 06 Nov, 2017 2 commits
-
-
Christoffer Dall authored
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>
-
Christoffer Dall authored
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>
-
- 19 Oct, 2017 2 commits
-
-
Mark Rutland authored
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: 25528213 ("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>
-
Ard Biesheuvel authored
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>
-
- 13 Oct, 2017 1 commit
-
-
Julien Thierry authored
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>
-
- 10 Aug, 2017 2 commits
-
-
Matthias Kaehlcke authored
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: c2743a36 ("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>
-
Marc Zyngier authored
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.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
- 14 Jun, 2017 2 commits
-
-
Daniel Lezcano authored
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>
-
Daniel Lezcano authored
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>
-
- 12 Jun, 2017 1 commit
-
-
Frank Rowand authored
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: c389d701 ("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>
-
- 09 May, 2017 1 commit
-
-
Sudeep Holla authored
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: c389d701 ("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.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 20 Apr, 2017 1 commit
-
-
Arnd Bergmann authored
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: 01d3e3ff ("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.deSigned-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 19 Apr, 2017 6 commits
-
-
Fu Wei authored
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>
-
Fu Wei authored
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>
-
Fu Wei authored
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>
-
Fu Wei authored
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>
-
Fu Wei authored
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>
-
Fu Wei authored
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>
-
- 10 Apr, 2017 1 commit
-
-
Fu Wei authored
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>
-