1. 14 9月, 2008 1 次提交
  2. 06 9月, 2008 2 次提交
    • L
      [ARM] 5241/1: provide ioremap_wc() · 1ad77a87
      Lennert Buytenhek 提交于
      This patch provides an ARM implementation of ioremap_wc().
      
      We use different page table attributes depending on which CPU we
      are running on:
      
      - Non-XScale ARMv5 and earlier systems: The ARMv5 ARM documents four
        possible mapping types (CB=00/01/10/11).  We can't use any of the
        cached memory types (CB=10/11), since that breaks coherency with
        peripheral devices.  Both CB=00 and CB=01 are suitable for _wc, and
        CB=01 (Uncached/Buffered) allows the hardware more freedom than
        CB=00, so we'll use that.
      
        (The ARMv5 ARM seems to suggest that CB=01 is allowed to delay stores
        but isn't allowed to merge them, but there is no other mapping type
        we can use that allows the hardware to delay and merge stores, so
        we'll go with CB=01.)
      
      - XScale v1/v2 (ARMv5): same as the ARMv5 case above, with the slight
        difference that on these platforms, CB=01 actually _does_ allow
        merging stores.  (If you want noncoalescing bufferable behavior
        on Xscale v1/v2, you need to use XCB=101.)
      
      - Xscale v3 (ARMv5) and ARMv6+: on these systems, we use TEXCB=00100
        mappings (Inner/Outer Uncacheable in xsc3 parlance, Uncached Normal
        in ARMv6 parlance).
      
        The ARMv6 ARM explicitly says that any accesses to Normal memory can
        be merged, which makes Normal memory more suitable for _wc mappings
        than Device or Strongly Ordered memory, as the latter two mapping
        types are guaranteed to maintain transaction number, size and order.
        We use the Uncached variety of Normal mappings for the same reason
        that we can't use C=1 mappings on ARMv5.
      
        The xsc3 Architecture Specification documents TEXCB=00100 as being
        Uncacheable and allowing coalescing of writes, which is also just
        what we need.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1ad77a87
    • D
      Revert "[ARM] use the new byteorder headers" · b35de672
      David Woodhouse 提交于
      This reverts commit ae82cbfc. It
      needs the new byteorder headers to be exported to userspace, and
      they aren't yet -- and probably shouldn't be, at this point in the
      2.6.27 release cycle (or ever, for that matter).
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b35de672
  3. 28 8月, 2008 1 次提交
  4. 17 8月, 2008 1 次提交
  5. 16 8月, 2008 1 次提交
    • N
      [ARM] 5196/1: fix inline asm constraints for preload · 16f719de
      Nicolas Pitre 提交于
      With gcc 4.3 and later, a pointer that has already been dereferenced is
      assumed not to be null since it should have caused a segmentation fault
      otherwise, hence any subsequent test against NULL is optimized away.
      
      Current inline asm constraint used in the implementation of prefetch()
      makes gcc believe that the pointer is dereferenced even though the PLD
      instruction does not load any data and does not cause a segmentation
      fault on null pointers, which causes all sorts of interesting results
      when reaching the end of a linked lists for example.
      
      Let's use a better constraint to properly represent the actual usage of
      the pointer value.
      
      Problem reported by Chris Steel.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      16f719de
  6. 15 8月, 2008 1 次提交
  7. 13 8月, 2008 2 次提交
  8. 10 8月, 2008 2 次提交
  9. 09 8月, 2008 1 次提交
    • L
      [ARM] prevent crashing when too much RAM installed · 60296c71
      Lennert Buytenhek 提交于
      This patch will truncate and/or ignore memory banks if their kernel
      direct mappings would (partially) overlap with the vmalloc area or
      the mappings between the vmalloc area and the address space top, to
      prevent crashing during early boot if there happens to be more RAM
      installed than we are expecting.
      
      Since the start of the vmalloc area is not at a fixed address (but
      the vmalloc end address is, via the per-platform VMALLOC_END define),
      a default area of 128M is reserved for vmalloc mappings, which can
      be shrunk or enlarged by passing an appropriate vmalloc= command line
      option as it is done on x86.
      
      On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe000000,
      two 512M RAM banks and vmalloc=128M (the default), this patch gives:
      
      	Truncating RAM at 20000000-3fffffff to -35ffffff (vmalloc region overlap).
      	Memory: 512MB 352MB = 864MB total
      
      On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe800000,
      two 256M RAM banks and vmalloc=768M, this patch gives:
      
      	Truncating RAM at 00000000-0fffffff to -0e7fffff (vmalloc region overlap).
      	Ignoring RAM at 10000000-1fffffff (vmalloc region overlap).
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Tested-by: NRiku Voipio <riku.voipio@iki.fi>
      60296c71
  10. 07 8月, 2008 3 次提交
  11. 03 8月, 2008 1 次提交