1. 11 10月, 2013 2 次提交
  2. 04 7月, 2013 1 次提交
  3. 30 5月, 2013 2 次提交
  4. 17 2月, 2013 1 次提交
  5. 14 2月, 2013 1 次提交
    • A
      ARM: disable virt_to_bus/virt_to_bus almost everywhere · a5d533ee
      Arnd Bergmann 提交于
      We are getting a number of warnings about the use of the deprecated
      bus_to_virt function in drivers using the ARM ISA DMA API:
      
      drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma':
      drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated
      (declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations]
      
      This is only because that function gets used by the inline
      set_dma_addr() helper. We know that any driver for the ISA DMA API
      is correctly using the DMA addresses, so we can change this
      to use the __bus_to_virt() function instead, which does not warn.
      
      After this, there are no remaining drivers that are used on
      any defconfigs on ARM using virt_to_bus or bus_to_virt, with
      the exception of the OSS sound driver. That driver is only used
      on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS
      on all other platforms and hide the deprecated functions, which
      is far more effective than marking them as deprecated, in order
      to avoid any new users of that code.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      a5d533ee
  6. 08 2月, 2013 1 次提交
  7. 02 10月, 2012 1 次提交
  8. 08 9月, 2012 1 次提交
  9. 29 6月, 2012 1 次提交
  10. 24 3月, 2012 1 次提交
  11. 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
  12. 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
  13. 22 8月, 2011 1 次提交
  14. 13 8月, 2011 1 次提交
  15. 12 7月, 2011 1 次提交
  16. 12 5月, 2011 2 次提交
  17. 18 2月, 2011 4 次提交
  18. 26 1月, 2011 1 次提交
  19. 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
  20. 16 7月, 2010 2 次提交
  21. 16 2月, 2010 2 次提交
  22. 23 11月, 2009 2 次提交
  23. 19 10月, 2009 1 次提交
  24. 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
  25. 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
  26. 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
  27. 28 11月, 2008 2 次提交
  28. 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
  29. 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