1. 27 7月, 2011 4 次提交
  2. 23 7月, 2011 13 次提交
  3. 29 5月, 2011 4 次提交
  4. 27 5月, 2011 2 次提交
  5. 25 5月, 2011 12 次提交
  6. 14 4月, 2011 1 次提交
    • G
      Blackfin: SMP: make all barriers handle cache issues · 943aee0c
      Graf Yang 提交于
      When suspending/resuming, the common task freezing code will run in
      parallel and freeze processes on each core.  This is because the code
      uses the non-smp version of memory barriers (as well it should).
      
      The Blackfin smp barrier logic at the moment contains the cache sync
      logic, but the non-smp barriers do not.  This is incorrect as Rafel
      summarized:
      > ...
      > The existing memory barriers are SMP barriers too, but they are more
      > than _just_ SMP barriers.  At least that's how it is _supposed_ to be
      > (eg. rmb() is supposed to be stronger than smp_rmb()).
      > ...
      > However, looking at the blackfin's definitions of SMP barriers I see
      > that it uses extra stuff that should _also_ be used in the definitions
      > of the mandatory barriers.
      > ...
      
      URL: http://lkml.org/lkml/2011/4/13/11
      LKML-Reference: <BANLkTi=F-C-vwX4PGGfbkdTBw3OWL-twfg@mail.gmail.com>
      Signed-off-by: NGraf Yang <graf.yang@analog.com>
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      943aee0c
  7. 31 3月, 2011 1 次提交
  8. 26 3月, 2011 1 次提交
  9. 24 3月, 2011 2 次提交
    • A
      bitops: remove minix bitops from asm/bitops.h · 61f2e7b0
      Akinobu Mita 提交于
      minix bit operations are only used by minix filesystem and useless by
      other modules.  Because byte order of inode and block bitmaps is different
      on each architecture like below:
      
      m68k:
      	big-endian 16bit indexed bitmaps
      
      h8300, microblaze, s390, sparc, m68knommu:
      	big-endian 32 or 64bit indexed bitmaps
      
      m32r, mips, sh, xtensa:
      	big-endian 32 or 64bit indexed bitmaps for big-endian mode
      	little-endian bitmaps for little-endian mode
      
      Others:
      	little-endian bitmaps
      
      In order to move minix bit operations from asm/bitops.h to architecture
      independent code in minix filesystem, this provides two config options.
      
      CONFIG_MINIX_FS_BIG_ENDIAN_16BIT_INDEXED is only selected by m68k.
      CONFIG_MINIX_FS_NATIVE_ENDIAN is selected by the architectures which use
      native byte order bitmaps (h8300, microblaze, s390, sparc, m68knommu,
      m32r, mips, sh, xtensa).  The architectures which always use little-endian
      bitmaps do not select these options.
      
      Finally, we can remove minix bit operations from asm/bitops.h for all
      architectures.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NGreg Ungerer <gerg@uclinux.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NPaul Mundt <lethal@linux-sh.org>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      61f2e7b0
    • A
      bitops: remove ext2 non-atomic bitops from asm/bitops.h · f312eff8
      Akinobu Mita 提交于
      As the result of conversions, there are no users of ext2 non-atomic bit
      operations except for ext2 filesystem itself.  Now we can put them into
      architecture independent code in ext2 filesystem, and remove from
      asm/bitops.h for all architectures.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f312eff8