1. 10 10月, 2008 1 次提交
    • N
      [ARM] 5295/1: make ZONE_DMA optional · 3bca103a
      Nicolas Pitre 提交于
      Most ARM machines don't need a special "DMA" memory zone, and
      when configured out, the kernel becomes a bit smaller:
      
      |   text    data     bss     dec     hex filename
      |3826182  102384  111700 4040266  3da64a vmlinux
      |3823593  101616  111700 4036909  3d992d vmlinux.nodmazone
      
      This is because the system now has only one zone total which effect is
      to optimize away many conditionals in page allocation paths.
      
      So let's configure this zone only on machines that need split zones.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3bca103a
  2. 01 10月, 2008 1 次提交
  3. 01 9月, 2008 1 次提交
  4. 10 8月, 2008 1 次提交
  5. 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
  6. 07 8月, 2008 1 次提交
  7. 03 8月, 2008 1 次提交
  8. 19 4月, 2008 1 次提交
  9. 01 12月, 2006 1 次提交
    • R
      [ARM] Clean up discontigmem support · b7dc96d7
      Russell King 提交于
      Most architectures have fairly simple discontiguous memory - a
      simple set of successive regions each containing some memory.
      These can be described simply as a log2 of their maximum size,
      along with the base address of the first region and the number
      of regions.
      
      The base address is already described by PHYS_PFN_OFFSET, and
      the number of regions via the MAX_NUMNODES and the number of
      online nodes.
      
      If we then supply the log2 of their maximum size, all the other
      discontigmem macros can move into generic code.
      
      There is one exception: lh7a40x seems to have a more complicated
      setup; this is left alone.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b7dc96d7
  10. 02 7月, 2006 1 次提交
  11. 30 6月, 2006 1 次提交
    • R
      [ARM] Add section support to ioremap · ff0daca5
      Russell King 提交于
      Allow section mappings to be setup using ioremap() and torn down
      with iounmap().  This requires additional support in the MM
      context switch to ensure that mappings are properly synchronised
      when mapped in.
      
      Based an original implementation by Deepak Saxena, reworked and
      ARMv6 support added by rmk.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ff0daca5
  12. 29 6月, 2006 1 次提交
    • R
      [ARM] nommu: adjust headers for !MMU ARM systems · 002547b4
      Russell King 提交于
      Majorily based on Hyok Choi's patches, this fixes up the asm-arm
      header files for mmuless systems.  Over and above Hyok's patches:
      
      - nommu.h merged into mmu.h (it's only a structure)
      - nommu_context.h is essentially the same as mmu_context.h, but
        without the MM switching code.
      
      so there's no point having separate files.  Also, in memory.h,
      there's no point #ifndef'ing PHYS_OFFSET and END_MEM - both
      CONFIG_DRAM_BASE and CONFIG_DRAM_SIZE will always be set by the
      configuration scripts.
      
      Other files have minor formatting changes, but are essentially
      the same.  Hyok's original patches were signed off thusly:
      Signed-off-by: NHyok S. Choi <hyok.choi@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      002547b4
  13. 26 4月, 2006 1 次提交
  14. 04 4月, 2006 2 次提交
  15. 02 4月, 2006 1 次提交
    • L
      [ARM] 3439/2: xsc3: add I/O coherency support · 23759dc6
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      This patch adds support for the I/O coherent cache available on the
      xsc3.  The approach is to provide a simple API to determine whether the
      chipset supports coherency by calling arch_is_coherent() and then
      setting the appropriate system memory PTE and PMD bits.  In addition,
      we call this API on dma_alloc_coherent() and dma_map_single() calls.
      A generic version exists that will compile out all the coherency-related
      code that is not needed on the majority of ARM systems.
      
      Note that we do not check for coherency in the dma_alloc_writecombine()
      function as that still requires a special PTE setting.  We also don't
      touch dma_mmap_coherent() as that is a special ARM-only API that is by
      definition only used on non-coherent system.
      Signed-off-by: NDeepak Saxena <dsaxena@plexity.net>
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      23759dc6
  16. 28 3月, 2006 1 次提交
  17. 13 1月, 2006 1 次提交
  18. 10 1月, 2006 1 次提交
    • D
      [ARM] 3070/2: Add __ioremap_pfn() API · 9d4ae727
      Deepak Saxena 提交于
      Patch from Deepak Saxena
      
      In working on adding 36-bit addressed supersection support to ioremap(),
      I came to the conclusion that it would be far simpler to do so by just
      splitting __ioremap() into a main external interface and adding an
      __ioremap_pfn() function that takes a pfn + offset into the page that
      __ioremap() can call. This way existing callers of __ioremap() won't have
      to change their code and 36-bit systems will just call __ioremap_pfn()
      and we will not have to deal with unsigned long long variables.
      
      Note that __ioremap_pfn() should _NOT_ be called directly by drivers
      but is reserved for use by arch_ioremap() implementations that map
      32-bit resource regions into the real 36-bit address and then call
      this new function.
      Signed-off-by: NDeepak Saxena <dsaxena@plexity.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9d4ae727
  19. 05 12月, 2005 1 次提交
  20. 30 10月, 2005 2 次提交
  21. 15 9月, 2005 1 次提交
    • R
      [ARM] Tighten pfn_valid() test. · 1b3cb73f
      Russell King 提交于
      Thomas Gleixner reported that mmaping and unmapping each physical
      page in turn eventually caused the kernel to oops.  It appears
      that pfn_valid() in the discontigmem case was too simplistic for
      proper operation.
      
      Tighten the logic so we also check if the PFN is within the range
      of the selected memory node.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1b3cb73f
  22. 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