1. 14 May, 2021 2 commits
    • Gunter Grau's avatar
      ipipe: arm: arm_global_timer: Use 64 Bit hw counter for ipipe_tsc · 6b588b7d
      Gunter Grau authored
      
      
      When using the arm_global_timer as source for ipipe_tsc the mask
      was configured with 32 Bit.
      However this timer is a native 64 Bit counter. So use the complete
      hardware register by configuring a 64 Bit mask on initialization.
      The ipipe_tsc implementation is already 64 Bit ready and reads this
      register as described in the reference manual, so no further
      changes needed.
      Signed-off-by: default avatarGunter Grau <gunter.grau@philips.com>
      Signed-off-by: Greg Gallagher's avatarGreg Gallagher <greg@embeddedgreg.com>
      6b588b7d
    • Gunter Grau's avatar
      ipipe: arm: ipipe_tsc: Use WRTIE_ONCE for updating last_tsc · 2830f9c0
      Gunter Grau authored
      The gcc 8.3 compiler generated for the update of the last_tsc
      8 byte value two store commands (see __ipipe_update_tsc).
      
              e2500001        subs    r0, r0, #1
              e5830000        str     r0, [r3]
              e2c11000        sbc     r1, r1, #0
              e5831004        str     r1, [r3, #4]
      
      This may lead to wrong reading of the counter in the assembler part
      __ipipe_tsc_get if a CPU core just reads this value when only half
      of the last_tsc field is updated.
      
              __ipipe_freerunning_32:
              ldr     r0, .LCfr32_cntr_addr
              /* User-space entry-point: r0 is the hardware counter virtual addre=
      ss */
              myldrd  r2, r3, r1, .LCfr32_last_tsc
              #ifndef CONFIG_CPU_BIG_ENDIAN
              /* Little endian */
              ldr     r0, [r0]
              cmp     r2, r0
              adc     r1, r3, #0
      
      The issue can be seen when enabling DEBUG_TIMEKEEPING option in the
      kernel and may lead to a jump backwards in time for the monotonic
      timer in Linux.
      
      WARNI...
      2830f9c0
  2. 03 May, 2021 1 commit
  3. 22 Jun, 2020 8 commits
  4. 20 Jun, 2020 1 commit
  5. 02 Mar, 2020 1 commit
    • Greg Gallagher's avatar
      arm: ipipe: Fix up the omap-gpio driver to deliver interrupts properly to the pipeline · c041e938
      Greg Gallagher authored
      
      
      OMAP gpio driver was changed upstream to be able to support threaded IRQ handler,
      this change impacted how the ipipe dealt with this driver. Since the ipipe expects
      a chained handler and now it's a generic one, we need to ack the event in the
      interrupt controller before calling the handler and unmask it after.
      
      Level flow handler must be used for pipelined interrupts. Since the IRQ handler
       on the root stage may be delayed until the real-time core releases the CPU, we
      need to mask the IRQ to prevent an IRQ storm when the interrupts are enabled again.
      
      Convert wa_lock to ipipe_spinlock, since wa_lock is used in the irq_chip functions
      which when called from the head stage can't use a Linux kernel service.
      
      Add the hold/release handlers for robustness.
      Signed-off-by: Greg Gallagher's avatarGreg Gallagher <greg@embeddedgreg.com>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      c041e938
  6. 12 Dec, 2019 3 commits
    • Philippe Gerum's avatar
      ipipe: timer: allocate cpumask dynamically · bd12153d
      Philippe Gerum authored
      When a huge number of CPUs is available (e.g. CONFIG_MAXSMP/x86), we
      might overflow the stack with cpumask_t variables in
      ipipe_select_timer(). Allocate the cpumask we need there dynamically
      instead.
      bd12153d
    • Philippe Gerum's avatar
      ipipe: switch potentially large cpumask to static storage · 0539486f
      Philippe Gerum authored
      When a huge number of CPUs is available (e.g. CONFIG_MAXSMP/x86), we
      might overflow the stack with cpumask_t variables in
      ipipe_critical_enter().
      
      Instead of allocating cpumask_var_t dynamically for these, rely on the
      fact that we cannot reenter the code accessing them by design, so
      those variables may be moved to local static storage.
      0539486f
    • Philippe Gerum's avatar
      ipipe: add 4th mapping level to interrupt log · 23ff222e
      Philippe Gerum authored
      Some configurations may define more than 256K distinct interrupts
      (e.g. CONFIG_MAXSMP/x86), which is the limit for the current 3-level
      mapping used for logging IRQs. Add a 4th mapping level to support
      configurations up to 16M interrupts.
      23ff222e
  7. 16 Nov, 2019 1 commit
  8. 15 Nov, 2019 1 commit
  9. 08 Nov, 2019 22 commits