1. 05 11月, 2013 1 次提交
  2. 01 2月, 2013 1 次提交
  3. 11 10月, 2012 1 次提交
    • J
      Improve atomic.h robustness · b4f2a17b
      Joshua Kinard 提交于
      I've maintained this patch, originally from Thiemo Seufer in 2004, for a
      really long time, but I think it's time for it to get a look at for
      possible inclusion.  I have had no problems with it across various SGI
      systems over the years.
      
      To quote the post here:
      http://www.linux-mips.org/archives/linux-mips/2004-12/msg00000.html
      
      "the atomic functions use so far memory references for the inline
      assembler to access the semaphore. This can lead to additional
      instructions in the ll/sc loop, because newer compilers don't
      expand the memory reference any more but leave it to the assembler.
      
      The appended patch uses registers instead, and makes the ll/sc
      arguments more explicit. In some cases it will lead also to better
      register scheduling because the register isn't bound to an output
      any more."
      Signed-off-by: NJoshua Kinard <kumba@gentoo.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/4029/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b4f2a17b
  4. 29 3月, 2012 1 次提交
  5. 27 7月, 2011 3 次提交
  6. 30 10月, 2010 1 次提交
    • R
      MIPS: Get rid of branches to .subsections. · 7837314d
      Ralf Baechle 提交于
      It was a nice optimization - on paper at least.  In practice it results in
      branches that may exceed the maximum legal range for a branch.  We can
      fight that problem with -ffunction-sections but -ffunction-sections again
      is incompatible with -pg used by the function tracer.
      
      By rewriting the loop around all simple LL/SC blocks to C we reduce the
      amount of inline assembler and at the same time allow GCC to often fill
      the branch delay slots with something sensible or whatever else clever
      optimization it may have up in its sleeve.
      
      With this optimization gone we also no longer need -ffunction-sections,
      so drop it.
      
      This optimization was originally introduced in 2.6.21, commit
      5999eca25c1fd4b9b9aca7833b04d10fe4bc877d (linux-mips.org) rsp.
      f65e4fa8 (kernel.org).
      
      Original fix for the issues which caused me to pull this optimization by
      Paul Gortmaker <paul.gortmaker@windriver.com>.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      7837314d
  7. 05 10月, 2010 1 次提交
  8. 27 7月, 2010 1 次提交
  9. 17 5月, 2010 1 次提交
  10. 27 2月, 2010 1 次提交
  11. 18 9月, 2009 1 次提交
  12. 12 6月, 2009 1 次提交
  13. 31 1月, 2009 1 次提交
  14. 07 1月, 2009 1 次提交
  15. 11 10月, 2008 1 次提交
  16. 04 7月, 2008 1 次提交
    • R
      [MIPS] Fix bug in atomic_sub_if_positive. · 50952026
      Ralf Baechle 提交于
      The branch optimization fixes in 2.6.21 introduced a bug in
      atomic_sub_if_positive that causes it to return even when the sc
      instruction fails. The result is that e.g. down_trylock becomes unreliable
      as the semaphore counter is not always decremented.
      
      Original MUA-shredded patch from Morten Larsen <mlarsen@broadcom.com>.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      50952026
  17. 12 10月, 2007 1 次提交
  18. 21 7月, 2007 1 次提交
  19. 11 5月, 2007 1 次提交
  20. 09 5月, 2007 2 次提交
  21. 17 3月, 2007 1 次提交
  22. 14 2月, 2007 1 次提交
    • R
      [MIPS] Improve branch prediction in ll/sc atomic operations. · f65e4fa8
      Ralf Baechle 提交于
      Now that finally all supported versions of binutils have functioning
      support for .subsection use .subsection to tweak the branch prediction
      
      I did not modify the R10000 errata variants because it seems unclear if
      this will invalidate the workaround which actually relies on the cheesy
      prediction of branch likely to cause a misspredict if the sc was
      successful.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f65e4fa8
  23. 05 12月, 2006 2 次提交
  24. 30 11月, 2006 1 次提交
  25. 14 7月, 2006 1 次提交
  26. 26 4月, 2006 1 次提交
  27. 28 2月, 2006 1 次提交
  28. 10 1月, 2006 2 次提交
  29. 07 1月, 2006 1 次提交
  30. 18 11月, 2005 1 次提交
  31. 14 11月, 2005 2 次提交
  32. 30 10月, 2005 2 次提交
  33. 05 9月, 2005 1 次提交