1. 16 7月, 2010 2 次提交
  2. 16 2月, 2010 2 次提交
  3. 23 11月, 2009 2 次提交
  4. 19 10月, 2009 1 次提交
  5. 12 9月, 2009 1 次提交
    • R
      ARM: Fix pfn_valid() for sparse memory · b7cfda9f
      Russell King 提交于
      On OMAP platforms, some people want to declare to segment up the memory
      between the kernel and a separate application such that there is a hole
      in the middle of the memory as far as Linux is concerned.  However,
      they want to be able to mmap() the hole.
      
      This currently causes problems, because update_mmu_cache() thinks that
      there are valid struct pages for the "hole".  Fix this by making
      pfn_valid() slightly more expensive, by checking whether the PFN is
      contained within the meminfo array.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: NKhasim Syed Mohammed <khasim@ti.com>
      b7cfda9f
  6. 24 7月, 2009 1 次提交
    • C
      Thumb-2: Add support for loadable modules · adca6dc2
      Catalin Marinas 提交于
      Modules compiled to Thumb-2 have two additional relocations needing to
      be resolved at load time, R_ARM_THM_CALL and R_ARM_THM_JUMP24, for BL
      and B.W instructions. The maximum Thumb-2 addressing range is +/-2^24
      (+/-16MB) therefore the MODULES_VADDR macro in asm/memory.h is set to
      (MODULES_END - 8MB) for the Thumb-2 compiled kernel.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      adca6dc2
  7. 16 3月, 2009 2 次提交
    • N
      [ARM] make page_to_dma() highmem aware · 58edb515
      Nicolas Pitre 提交于
      If a machine class has a custom __virt_to_bus() implementation then it
      must provide a __arch_page_to_dma() implementation as well which is
      _not_ based on page_address() to support highmem.
      
      This patch fixes existing __arch_page_to_dma() and provide a default
      implementation otherwise.  The default implementation for highmem is
      based on __pfn_to_bus() which is defined only when no custom
      __virt_to_bus() is provided by the machine class.
      
      That leaves only ebsa110 and footbridge which cannot support highmem
      until they provide their own __arch_page_to_dma() implementation.
      But highmem support on those legacy platforms with limited memory is
      certainly not a priority.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      58edb515
    • N
      [ARM] kmap support · d73cd428
      Nicolas Pitre 提交于
      The kmap virtual area borrows a 2MB range at the top of the 16MB area
      below PAGE_OFFSET currently reserved for kernel modules and/or the
      XIP kernel.  This 2MB corresponds to the range covered by 2 consecutive
      second-level page tables, or a single pmd entry as seen by the Linux
      page table abstraction.  Because XIP kernels are unlikely to be seen
      on systems needing highmem support, there shouldn't be any shortage of
      VM space for modules (14 MB for modules is still way more than twice the
      typical usage).
      
      Because the virtual mapping of highmem pages can go away at any moment
      after kunmap() is called on them, we need to bypass the delayed cache
      flushing provided by flush_dcache_page() in that case.
      
      The atomic kmap versions are based on fixmaps, and
      __cpuc_flush_dcache_page() is used directly in that case.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      d73cd428
  8. 28 11月, 2008 2 次提交
  9. 07 11月, 2008 1 次提交
    • R
      [ARM] fix naming of MODULE_START / MODULE_END · ab4f2ee1
      Russell King 提交于
      As of 73bdf0a6, the kernel needs
      to know where modules are located in the virtual address space.
      On ARM, we located this region between MODULE_START and MODULE_END.
      Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END.
      Update ARM to use the same naming, so is_vmalloc_or_module_addr()
      can work properly.  Also update the comment on mm/vmalloc.c to
      reflect that ARM also places modules in a separate region from the
      vmalloc space.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ab4f2ee1
  10. 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
  11. 01 10月, 2008 1 次提交
  12. 01 9月, 2008 1 次提交
  13. 10 8月, 2008 1 次提交
  14. 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
  15. 07 8月, 2008 1 次提交
  16. 03 8月, 2008 1 次提交
  17. 19 4月, 2008 1 次提交
  18. 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
  19. 02 7月, 2006 1 次提交
  20. 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
  21. 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
  22. 26 4月, 2006 1 次提交
  23. 04 4月, 2006 2 次提交
  24. 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
  25. 28 3月, 2006 1 次提交
  26. 13 1月, 2006 1 次提交
  27. 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
  28. 05 12月, 2005 1 次提交
  29. 30 10月, 2005 2 次提交
  30. 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
  31. 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