1. 02 10月, 2012 1 次提交
  2. 08 9月, 2012 1 次提交
  3. 29 6月, 2012 1 次提交
  4. 24 3月, 2012 1 次提交
  5. 14 10月, 2011 1 次提交
    • N
      ARM: switch from NO_MACH_MEMORY_H to NEED_MACH_MEMORY_H · 0cdc8b92
      Nicolas Pitre 提交于
      Given that we want the default to not have any <mach/memory.h> and given
      that there are now fewer cases where it is still provided than the cases
      where it is not at this point, this makes sense to invert the logic and
      just identify the exception cases.
      
      The word "need" instead of "have" was chosen to construct the config
      symbol so not to suggest that having a mach/memory.h file is actually
      a feature that one should aim for.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      0cdc8b92
  6. 26 9月, 2011 1 次提交
    • N
      ARM: prepare for removal of a bunch of <mach/memory.h> files · 1b9f95f8
      Nicolas Pitre 提交于
      When the CONFIG_NO_MACH_MEMORY_H symbol is selected by a particular
      machine class, the machine specific memory.h include file is no longer
      used and can be removed.  In that case the equivalent information can
      be obtained dynamically at runtime by enabling CONFIG_ARM_PATCH_PHYS_VIRT
      or by specifying the physical memory address at kernel configuration time.
      
      If/when all instances of mach/memory.h are removed then this symbol could
      be removed.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      1b9f95f8
  7. 22 8月, 2011 1 次提交
  8. 13 8月, 2011 1 次提交
  9. 12 7月, 2011 1 次提交
  10. 12 5月, 2011 2 次提交
  11. 18 2月, 2011 4 次提交
  12. 26 1月, 2011 1 次提交
  13. 27 7月, 2010 1 次提交
    • L
      ARM: 6225/1: make TCM allocation static and common for all archs · 1dbd30e9
      Linus Walleij 提交于
      This changes the TCM handling so that a fixed area is reserved at
      0xfffe0000-0xfffeffff for TCM. This areas is used by XScale but
      XScale does not have TCM so the mechanisms are mutually exclusive.
      
      This change is needed to make TCM detection more dynamic while
      still being able to compile code into it, and is a must for the
      unified ARM goals: the current TCM allocation at different places
      in memory for each machine would be a nightmare if you want to
      compile a single image for more than one machine with TCM so it
      has to be nailed down in one place.
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1dbd30e9
  14. 16 7月, 2010 2 次提交
  15. 16 2月, 2010 2 次提交
  16. 23 11月, 2009 2 次提交
  17. 19 10月, 2009 1 次提交
  18. 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
  19. 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
  20. 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
  21. 28 11月, 2008 2 次提交
  22. 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
  23. 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
  24. 01 10月, 2008 1 次提交
  25. 01 9月, 2008 1 次提交
  26. 10 8月, 2008 1 次提交
  27. 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
  28. 07 8月, 2008 1 次提交
  29. 03 8月, 2008 1 次提交
  30. 19 4月, 2008 1 次提交
  31. 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