1. 22 6月, 2015 1 次提交
    • V
      ARCv2: Support for ARCv2 ISA and HS38x cores · 1f6ccfff
      Vineet Gupta 提交于
      The notable features are:
          - SMP configurations of upto 4 cores with coherency
          - Optional L2 Cache and IO-Coherency
          - Revised Interrupt Architecture (multiple priorites, reg banks,
              auto stack switch, auto regfile save/restore)
          - MMUv4 (PIPT dcache, Huge Pages)
          - Instructions for
      	* 64bit load/store: LDD, STD
      	* Hardware assisted divide/remainder: DIV, REM
      	* Function prologue/epilogue: ENTER_S, LEAVE_S
      	* IRQ enable/disable: CLRI, SETI
      	* pop count: FFS, FLS
      	* SETcc, BMSKN, XBFU...
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      1f6ccfff
  2. 19 6月, 2015 1 次提交
  3. 12 12月, 2014 1 次提交
  4. 13 10月, 2014 1 次提交
  5. 23 7月, 2014 1 次提交
  6. 06 11月, 2013 1 次提交
  7. 26 8月, 2013 1 次提交
    • V
      ARC: Entry Handler tweaks: Optimize away redundant IRQ_DISABLE_SAVE · fce16bc3
      Vineet Gupta 提交于
      In the exception return path, for both U/K cases, intr are already
      disabled (for various existing reasons). So when we drop down to
      @restore_regs, we need not redo that.
      
      There was subtle issue - when intr were NOT being disabled for
      ret-to-kernel-but-no-preemption case - now fixed by moving the
      IRQ_DISABLE further up in @resume_kernel_mode.
      
      So what do we gain:
      
      * Shaves off a few insn in return path.
      
      * Eliminates the need for IRQ_DISABLE_SAVE assembler macro for ARCv2
        hence allows for entry code sharing.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      fce16bc3
  8. 22 6月, 2013 1 次提交
  9. 09 4月, 2013 1 次提交
    • C
      ARC: Add implicit compiler barrier to raw_local_irq* functions · 79e5f05e
      Christian Ruppert 提交于
      ARC irqsave/restore macros were missing the compiler barrier, causing a
      stale load in irq-enabled region be used in irq-safe region, despite
      being changed, because the register holding the value was still live.
      
      The problem manifested as random crashes in timer code when stress
      testing ARCLinux (3.9-rc3) on a !SMP && !PREEMPT_COUNT
      
      Here's the exact sequence which caused this:
       (0). tv1[x] <----> t1 <---> t2
       (1). mod_timer(t1) interrupted after it calls timer_pending()
       (2). mod_timer(t2) completes
       (3). mod_timer(t1) resumes but messes up the list
       (4). __runt_timers( ) uses bogus timer_list entry / crashes in
            timer->function
      
      Essentially mod_timer() was racing against itself and while the spinlock
      serialized the tv1[] timer link list, timer_pending() called outside the
      spinlock, cached timer link list element in a register.
      With low register pressure (and a deep register file), lack of barrier
      in raw_local_irqsave() as well as preempt_disable (!PREEMPT_COUNT
      version), there was nothing to force gcc to reload across the spinlock,
      causing a stale value in reg be used for link list manipulation - ensuing
      a corruption.
      
      ARcompact disassembly which shows the culprit generated code:
      
      mod_timer:
          push_s blink
          mov_s r13,r0	# timer, timer
      ..
          ###### timer_pending( )
          ld_s r3,[r13]       # <------ <variable>.entry.next LOADED
          brne r3, 0, @.L163
      
      .L163:
      ..
          ###### spin_lock_irq( )
          lr  r5, [status32]  # flags
          bic r4, r5, 6       # temp, flags,
          and.f 0, r5, 6      # flags,
          flag.nz r4
      
          ###### detach_if_pending( ) begins
      
          tst_s r3,r3  <--------------
      			# timer_pending( ) checks timer->entry.next
                              # r3 is NOT reloaded by gcc, using stale value
          beq.d @.L169
          mov.eq r0,0
      
          #####  detach_timer( ): __list_del( )
      
          ld r4,[r13,4]    	# <variable>.entry.prev, D.31439
          st r4,[r3,4]     	# <variable>.prev, D.31439
          st r3,[r4]       	# <variable>.next, D.30246
      
      We initially tried to fix this by adding barrier() to preempt_* macros
      for !PREEMPT_COUNT but Linus clarified that it was anything but wrong.
      http://www.spinics.net/lists/kernel/msg1512709.html
      
      [vgupta: updated commitlog]
      
      Reported-by/Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
      Cc: Christian Ruppert <christian.ruppert@abilis.com>
      Cc: Pierrick Hascoet <pierrick.hascoet@abilis.com>
      Debugged-by/Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      79e5f05e
  10. 16 2月, 2013 1 次提交
  11. 11 2月, 2013 1 次提交
    • V
      ARC: irqflags - Interrupt enabling/disabling at in-core intc · ac4c244d
      Vineet Gupta 提交于
      ARC700 has an in-core intc which provides 2 priorities (a.k.a.) "levels"
      of interrupts (per IRQ) hencforth referred to as L1/L2 interrupts.
      
      CPU flags register STATUS32 has Interrupt Enable bits per level (E1/E2)
      to globally enable (or disable) all IRQs at a level. Hence the
      implementation of arch_local_irq_{save,restore,enable,disable}( )
      
      The STATUS32 reg can be r/w only using the AUX Interface of ARC, hence
      the use of LR/SR instructions. Further, E1/E2 bits in there can only be
      updated using the FLAG insn.
      
      The intc supports 32 interrupts - and per IRQ enabling is controlled by
      a bit in the AUX_IENABLE register, hence the implmentation of
      arch_{,un}mask_irq( ) routines.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      ac4c244d