1. 19 10月, 2007 3 次提交
    • N
      mips: lock bitops · 728697cd
      Nick Piggin 提交于
      mips can avoid one mb when acquiring a lock with test_and_set_bit_lock.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      728697cd
    • N
      mips: fix bitops · c8f30ae5
      Nick Piggin 提交于
      Documentation/atomic_ops.txt defines these primitives must contain a memory
      barrier both before and after their memory operation.  This is consistent with
      the atomic ops implementation on mips.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c8f30ae5
    • N
      bitops: introduce lock ops · 26333576
      Nick Piggin 提交于
      Introduce test_and_set_bit_lock / clear_bit_unlock bitops with lock semantics.
      Convert all architectures to use the generic implementation.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Acked-By: NDavid Howells <dhowells@redhat.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Bryan Wu <bryan.wu@analog.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26333576
  2. 12 10月, 2007 1 次提交
  3. 21 7月, 2007 1 次提交
  4. 27 6月, 2007 1 次提交
  5. 12 6月, 2007 1 次提交
  6. 17 3月, 2007 1 次提交
  7. 07 3月, 2007 1 次提交
  8. 19 2月, 2007 1 次提交
  9. 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
  10. 05 12月, 2006 1 次提交
  11. 30 11月, 2006 2 次提交
  12. 14 7月, 2006 1 次提交
  13. 27 4月, 2006 1 次提交
  14. 26 4月, 2006 1 次提交
  15. 27 3月, 2006 2 次提交
  16. 07 2月, 2006 1 次提交
  17. 04 1月, 2006 1 次提交
  18. 30 10月, 2005 4 次提交
  19. 05 9月, 2005 2 次提交
  20. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4