An error occurred fetching the project authors.
  1. 05 Dec, 2020 1 commit
  2. 08 Jul, 2020 2 commits
  3. 22 May, 2020 1 commit
  4. 06 Mar, 2020 1 commit
  5. 25 Feb, 2020 1 commit
  6. 17 Feb, 2020 1 commit
  7. 25 Jun, 2019 1 commit
  8. 19 Jun, 2019 1 commit
  9. 12 Jun, 2019 1 commit
    • Julien Thierry's avatar
      clocksource/drivers/arm_arch_timer: Don't trace count reader functions · 5d6168fc
      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: default avatarJulien 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: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      5d6168fc
  10. 30 Apr, 2019 4 commits
  11. 16 Apr, 2019 1 commit
    • Andrew Murray's avatar
      arm64: HWCAP: add support for AT_HWCAP2 · aaba098f
      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: default avatarAndrew Murray <andrew.murray@arm.com>
      [will: use const_ilog2() and tweak documentation]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      aaba098f
  12. 11 Apr, 2019 1 commit
  13. 23 Feb, 2019 1 commit
    • Samuel Holland's avatar
      clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability · c950ca8c
      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: default avatarMarc 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: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Tested-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarSamuel Holland <samuel@sholland.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      c950ca8c
  14. 19 Feb, 2019 1 commit
  15. 01 Oct, 2018 1 commit
  16. 02 Aug, 2018 1 commit
  17. 10 Jul, 2018 1 commit
  18. 06 Nov, 2017 2 commits
    • Christoffer Dall's avatar
      arm64: Use physical counter for in-kernel reads when booted in EL2 · e6d68b00
      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: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      e6d68b00
    • Christoffer Dall's avatar
      arm64: Implement arch_counter_get_cntpct to read the physical counter · f2e600c1
      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: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      f2e600c1
  19. 19 Oct, 2017 2 commits
    • Mark Rutland's avatar
      clocksource/drivers/arm_arch_timer: Fix DEFINE_PER_CPU expansion · a7fb4577
      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: default avatarMark 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: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      a7fb4577
    • Ard Biesheuvel's avatar
      clocksource/drivers/arm_arch_timer: Validate CNTFRQ after enabling frame · 21492e13
      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: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      21492e13
  20. 13 Oct, 2017 1 commit
    • Julien Thierry's avatar
      arm_arch_timer: Expose event stream status · ec5c8e42
      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: default avatarJulien Thierry <julien.thierry@arm.com>
      Acked-by: default avatarMark 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: default avatarWill Deacon <will.deacon@arm.com>
      ec5c8e42
  21. 10 Aug, 2017 2 commits
  22. 14 Jun, 2017 2 commits
  23. 12 Jun, 2017 1 commit
  24. 09 May, 2017 1 commit
  25. 20 Apr, 2017 1 commit
    • Arnd Bergmann's avatar
      arm64/arch_timer: Mark errata handlers as __maybe_unused · eb645221
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarDaniel 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: default avatarThomas Gleixner <tglx@linutronix.de>
      eb645221
  26. 19 Apr, 2017 6 commits
  27. 10 Apr, 2017 1 commit
    • Fu Wei's avatar
      clocksource: arm_arch_timer: rework PPI selection · 4502b6bb
      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: default avatarFu Wei <fu.wei@linaro.org>
      Tested-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
      [Mark: reword commit message]
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      4502b6bb