1. 22 Feb, 2005 6 commits
  2. 21 Feb, 2005 11 commits
  3. 20 Feb, 2005 9 commits
  4. 19 Feb, 2005 6 commits
  5. 18 Feb, 2005 1 commit
  6. 19 Feb, 2005 1 commit
  7. 18 Feb, 2005 6 commits
    • Linus Torvalds's avatar
      Merge bk://bk.arm.linux.org.uk/linux-2.6-rmk · 41740fe8
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      41740fe8
    • Russell King's avatar
      [ARM] Take account of vm_pgoff for DMA mmap · 04320dad
      Russell King authored
      The DMA mmap code was ignoring vm_pgoff which prevented a partial
      mmap() of a DMA buffer.
      Signed-off-by: default avatarRussell King <rmk@arm.linux.org.uk>
      04320dad
    • Lennert Buytenhek's avatar
      [ARM PATCH] 2494/1: fix 'CONFGI_' -> 'CONFIG_' in mach-ixp2000/ixdp2x00.c · 7478a481
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      Fix a misspelled config symbol name in the ixp2000 code.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Russell King
      7478a481
    • Lennert Buytenhek's avatar
      [ARM PATCH] 2493/1: put IXP2000 slowport in 8-bit mode after boot · bb12ca40
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      This is an old patch from 2.6.9-rc3-ds2 that never made it upstream.
      The IXP2000 slowport has two modes of operation, 8-bit and 32-bit.
      The slowport itself is a byte-wide bus, and in 8-bit mode, it does the
      more-or-less obvious thing: every word read causes four byte reads,
      and those bytes are then combined into a word according to the xscale
      core's current endian setting.  So, what value you get depends on what
      endianity your IXP2000 is running in.
      In 32-bit mode, however, it is the slowport itself which combines
      bytes into words, and for this it unconditionally uses little endian
      mode.  In this mode, word reads from the slowport will return the
      same value no matter whether the xscale core is running in big or
      little endian mode.  This can be a plus in some cases.  Byte (and
      halfword) accesses in 32-bit mode have rather useless semantics
      due to this, though.
      The usefulness of 32-bit mode is limited to the initial boot.  When
      the IXP2000 resets, the slowport is always in 32-bit mode, so if you
      flash the bootloader into flash (which is connected to the slowport)
      using little-endian byte ordering, the xscale will always read the
      instruction stream correctly, no matter whether it's running in big
      or little endian mode.
      After booting it makes no sense to use 32-bit mode anymore.  Especially
      since the slowport's word ordering in 32-bit mode is little endian,
      and the IXP2000 is conventionally run in big endian, which gives all
      kinds of fun issues when trying to access peripherals connected to
      the slowport.
      In fact, the current MTD map driver for IXP2000 already sets the
      slowport to 8-bit mode because it cannot access the flash otherwise.
      However, this means that if the MTD map driver is not compiled in for
      some reason, the slowport will stay in 32-bit mode after the initial
      boot, which will cause peripheral accesses to unexpectedly break!
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Russell King
      bb12ca40
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/davem/sparc-2.6 · ed343ca9
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      ed343ca9
    • David S. Miller's avatar
      [SPARC64]: BUG on rediculious memcpy lengths. · 2b424f63
      David S. Miller authored
      Anything larger than MAX_INT is suspect.  Do this
      for user copies too.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b424f63