1. 27 8月, 2015 7 次提交
  2. 21 8月, 2015 1 次提交
  3. 20 8月, 2015 10 次提交
    • V
      09074950
    • Y
      ARC: change some branchs to jumps to resolve linkage errors · 6de6066c
      Yuriy Kolerov 提交于
      When kernel's binary becomes large enough (32M and more) errors
      may occur during the final linkage stage. It happens because
      the build system uses short relocations for ARC  by default.
      This problem may be easily resolved by passing -mlong-calls
      option to GCC to use long absolute jumps (j) instead of short
      relative branchs (b).
      
      But there are fragments of pure assembler code exist which use
      branchs in inappropriate places and cause a linkage error because
      of relocations overflow.
      
      First of these fragments is .fixup insertion in futex.h and
      unaligned.c. It inserts a code in the separate section (.fixup)
      with branch instruction. It leads to the linkage error when
      kernel becomes large.
      
      Second of these fragments is calling scheduler's functions
      (common kernel code) from entry.S of ARC's code. When kernel's
      binary becomes large it may lead to the linkage error because
      scheduler may occur far enough from ARC's code in the final
      binary.
      Signed-off-by: NYuriy Kolerov <yuriy.kolerov@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      6de6066c
    • V
      ARC: ensure futex ops are atomic in !LLSC config · eb2cd8b7
      Vineet Gupta 提交于
      W/o hardware assisted atomic r-m-w the best we can do is to disable
      preemption.
      
      Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Michel Lespinasse <walken@google.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      eb2cd8b7
    • V
      ARC: Enable HAVE_FUTEX_CMPXCHG · 5e057429
      Vineet Gupta 提交于
      ARC doesn't need the runtime detection of futex cmpxchg op
      
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      5e057429
    • V
      ARC: make futex_atomic_cmpxchg_inatomic() return bimodal · 882a95ae
      Vineet Gupta 提交于
      Callers of cmpxchg_futex_value_locked() in futex code expect bimodal
      return value:
        !0 (essentially -EFAULT as failure)
         0 (success)
      
      Before this patch, the success return value was old value of futex,
      which could very well be non zero, causing caller to possibly take the
      failure path erroneously.
      
      Fix that by returning 0 for success
      
      (This fix was done back in 2011 for all upstream arches, which ARC
      obviously missed)
      
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Michel Lespinasse <walken@google.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      882a95ae
    • V
      ARC: futex cosmetics · ed574e2b
      Vineet Gupta 提交于
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Michel Lespinasse <walken@google.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      ed574e2b
    • V
      ARC: add barriers to futex code · 31d30c82
      Vineet Gupta 提交于
      The atomic ops on futex need to provide the full barrier just like
      regular atomics in kernel.
      
      Also remove pagefault_enable/disable in futex_atomic_cmpxchg_inatomic()
      as core code already does that
      
      Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Michel Lespinasse <walken@google.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      31d30c82
    • A
      ARCv2: IOC: Allow boot time disable · 1648c70d
      Alexey Brodkin 提交于
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      1648c70d
    • V
      ARCv2: SLC: Allow boot time disable · 79335a2c
      Vineet Gupta 提交于
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      79335a2c
    • A
      ARCv2: Support IO Coherency and permutations involving L1 and L2 caches · f2b0b25a
      Alexey Brodkin 提交于
      In case of ARCv2 CPU there're could be following configurations
      that affect cache handling for data exchanged with peripherals
      via DMA:
       [1] Only L1 cache exists
       [2] Both L1 and L2 exist, but no IO coherency unit
       [3] L1, L2 caches and IO coherency unit exist
      
      Current implementation takes care of [1] and [2].
      Moreover support of [2] is implemented with run-time check
      for SLC existence which is not super optimal.
      
      This patch introduces support of [3] and rework of DMA ops
      usage. Instead of doing run-time check every time a particular
      DMA op is executed we'll have 3 different implementations of
      DMA ops and select appropriate one during init.
      
      As for IOC support for it we need:
       [a] Implement empty DMA ops because IOC takes care of cache
           coherency with DMAed data
       [b] Route dma_alloc_coherent() via dma_alloc_noncoherent()
           This is required to make IOC work in first place and also
           serves as optimization as LD/ST to coherent buffers can be
           srviced from caches w/o going all the way to memory
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      [vgupta:
        -Added some comments about IOC gains
        -Marked dma ops as static,
        -Massaged changelog a bit]
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      f2b0b25a
  4. 11 8月, 2015 1 次提交
  5. 07 8月, 2015 1 次提交
  6. 05 8月, 2015 1 次提交
    • V
      ARC: Make pt_regs regs unsigned · 87ce6280
      Vineet Gupta 提交于
      KGDB fails to build after f51e2f19 ("ARC: make sure instruction_pointer()
      returns unsigned value")
      
      The hack to force one specific reg to unsigned backfired. There's no
      reason to keep the regs signed after all.
      
      |  CC      arch/arc/kernel/kgdb.o
      |../arch/arc/kernel/kgdb.c: In function 'kgdb_trap':
      | ../arch/arc/kernel/kgdb.c:180:29: error: lvalue required as left operand of assignment
      |   instruction_pointer(regs) -= BREAK_INSTR_SIZE;
      Reported-by: NYuriy Kolerov <yuriy.kolerov@synopsys.com>
      Fixes: f51e2f19 ("ARC: make sure instruction_pointer() returns unsigned value")
      Cc: Alexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      87ce6280
  7. 04 8月, 2015 7 次提交
  8. 03 8月, 2015 1 次提交
  9. 23 7月, 2015 1 次提交
  10. 20 7月, 2015 4 次提交
  11. 18 7月, 2015 1 次提交
  12. 13 7月, 2015 2 次提交
    • V
      ARCv2: support HS38 releases · 624b71ee
      Vineet Gupta 提交于
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      624b71ee
    • A
      ARC: make sure instruction_pointer() returns unsigned value · f51e2f19
      Alexey Brodkin 提交于
      Currently instruction_pointer() returns pt_regs->ret and so return value
      is of type "long", which implicitly stands for "signed long".
      
      While that's perfectly fine when dealing with 32-bit values if return
      value of instruction_pointer() gets assigned to 64-bit variable sign
      extension may happen.
      
      And at least in one real use-case it happens already.
      In perf_prepare_sample() return value of perf_instruction_pointer()
      (which is an alias to instruction_pointer() in case of ARC) is assigned
      to (struct perf_sample_data)->ip (which type is "u64").
      
      And what we see if instuction pointer points to user-space application
      that in case of ARC lays below 0x8000_0000 "ip" gets set properly with
      leading 32 zeros. But if instruction pointer points to kernel address
      space that starts from 0x8000_0000 then "ip" is set with 32 leadig
      "f"-s. I.e. id instruction_pointer() returns 0x8100_0000, "ip" will be
      assigned with 0xffff_ffff__8100_0000. Which is obviously wrong.
      
      In particular that issuse broke output of perf, because perf was unable
      to associate addresses like 0xffff_ffff__8100_0000 with anything from
      /proc/kallsyms.
      
      That's what we used to see:
       ----------->8----------
        6.27%  ls       [unknown]                [k] 0xffffffff8046c5cc
        2.96%  ls       libuClibc-0.9.34-git.so  [.] memcpy
        2.25%  ls       libuClibc-0.9.34-git.so  [.] memset
        1.66%  ls       [unknown]                [k] 0xffffffff80666536
        1.54%  ls       libuClibc-0.9.34-git.so  [.] 0x000224d6
        1.18%  ls       libuClibc-0.9.34-git.so  [.] 0x00022472
       ----------->8----------
      
      With that change perf output looks much better now:
       ----------->8----------
        8.21%  ls       [kernel.kallsyms]        [k] memset
        3.52%  ls       libuClibc-0.9.34-git.so  [.] memcpy
        2.11%  ls       libuClibc-0.9.34-git.so  [.] malloc
        1.88%  ls       libuClibc-0.9.34-git.so  [.] memset
        1.64%  ls       [kernel.kallsyms]        [k] _raw_spin_unlock_irqrestore
        1.41%  ls       [kernel.kallsyms]        [k] __d_lookup_rcu
       ----------->8----------
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Cc: arc-linux-dev@synopsys.com
      Cc: stable@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      f51e2f19
  13. 09 7月, 2015 3 次提交