14 Oct, 2011

1 commit

  • Given that we want the default to not have any 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: Nicolas Pitre

    Nicolas Pitre
     

26 Sep, 2011

1 commit

  • 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: Nicolas Pitre

    Nicolas Pitre
     

30 Aug, 2011

1 commit


22 Aug, 2011

1 commit

  • This function can be called during boot to increase the size of the consistent
    DMA region above it's default value of 2MB. It must be called before the memory
    allocator is initialised, i.e. before any core_initcall.

    Signed-off-by: Jon Medhurst
    Acked-by: Nicolas Pitre

    Jon Medhurst
     

13 Aug, 2011

1 commit


12 Jul, 2011

1 commit


12 May, 2011

2 commits

  • Rather than each platform providing its own function to adjust the
    zone sizes, use the new ARM_DMA_ZONE_SIZE definition to perform this
    adjustment. This ensures that the actual DMA zone size and the
    ISA_DMA_THRESHOLD/MAX_DMA_ADDRESS definitions are consistent with
    each other, and moves this complexity out of the platform code.

    Acked-by: Nicolas Pitre
    Acked-by: Catalin Marinas
    Signed-off-by: Russell King

    Russell King
     
  • The values of ISA_DMA_THRESHOLD and MAX_DMA_ADDRESS are related; one is
    the physical/bus address, the other is the virtual address. Both need
    to be kept in step, so rather than having platforms define both, allow
    them to define a single macro which sets both of these macros
    appropraitely.

    Acked-by: Nicolas Pitre
    Acked-by: Catalin Marinas
    Signed-off-by: Russell King

    Russell King
     

18 Feb, 2011

4 commits

  • The unsigned long datatype is not sufficient for mapping physical addresses
    >= 4GB.

    This patch ensures that the address conversion code in asm/memory.h casts
    to the correct type when handling physical addresses. The internal v2p
    macros only deal with lowmem addresses, so these do not need to be modified.

    Acked-by: Catalin Marinas
    Signed-off-by: Will Deacon
    Signed-off-by: Russell King

    Will Deacon
     
  • MSM's memory is aligned to 2MB, which is more than we can do with our
    existing method as we're limited to the upper 8 bits. Extend this by
    using two instructions to 16 bits, automatically selected when MSM is
    enabled.

    Acked-by: Tony Lindgren
    Reviewed-by: Nicolas Pitre
    Tested-by: Nicolas Pitre
    Signed-off-by: Russell King

    Russell King
     
  • This idea came from Nicolas, Eric Miao produced an initial version,
    which was then rewritten into this.

    Patch the physical to virtual translations at runtime. As we modify
    the code, this makes it incompatible with XIP kernels, but allows us
    to achieve this with minimal loss of performance.

    As many translations are of the form:

    physical = virtual + (PHYS_OFFSET - PAGE_OFFSET)
    virtual = physical - (PHYS_OFFSET - PAGE_OFFSET)

    we generate an 'add' instruction for __virt_to_phys(), and a 'sub'
    instruction for __phys_to_virt(). We calculate at run time (PHYS_OFFSET
    - PAGE_OFFSET) by comparing the address prior to MMU initialization with
    where it should be once the MMU has been initialized, and place this
    constant into the above add/sub instructions.

    Once we have (PHYS_OFFSET - PAGE_OFFSET), we can calculate the real
    PHYS_OFFSET as PAGE_OFFSET is a build-time constant, and save this for
    the C-mode PHYS_OFFSET variable definition to use.

    At present, we are unable to support Realview with Sparsemem enabled
    as this uses a complex mapping function, and MSM as this requires a
    constant which will not fit in our math instruction.

    Add a module version magic string for this feature to prevent
    incompatible modules being loaded.

    Tested-by: Tony Lindgren
    Reviewed-by: Nicolas Pitre
    Tested-by: Nicolas Pitre
    Signed-off-by: Russell King

    Russell King
     
  • This uncouple PHYS_OFFSET from the platform definitions, thereby
    facilitating run-time computation of the physical memory offset.

    Acked-by: Nicolas Pitre
    Acked-by: Viresh Kumar
    Acked-by: H Hartley Sweeten
    Acked-by: Magnus Damm
    Acked-by: Tony Lindgren
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD
    Acked-by: Wan ZongShun
    Acked-by: Kukjin Kim
    Acked-by: Eric Miao
    Acked-by: Jiandong Zheng
    Signed-off-by: Russell King

    Russell King
     

26 Jan, 2011

1 commit


31 Jul, 2010

1 commit


27 Jul, 2010

1 commit

  • 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: Linus Walleij
    Signed-off-by: Russell King

    Linus Walleij
     

16 Jul, 2010

2 commits


16 Feb, 2010

2 commits


04 Dec, 2009

1 commit


23 Nov, 2009

2 commits


19 Oct, 2009

1 commit


12 Sep, 2009

2 commits

  • 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: Russell King
    Tested-by: Khasim Syed Mohammed

    Russell King
     

24 Jul, 2009

1 commit

  • 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: Catalin Marinas

    Catalin Marinas
     

16 Mar, 2009

2 commits

  • 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: Nicolas Pitre

    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: Nicolas Pitre

    Nicolas Pitre
     

28 Nov, 2008

2 commits

  • Let's provide an overridable default instead of having every machine
    class define __virt_to_bus and __bus_to_virt to the same thing. What
    most platforms are using is bus_addr == phys_addr so such is the default.

    One exception is ebsa110 which has no DMA what so ever, so the actual
    definition is not important except only for proper compilation. Also
    added a comment about the special footbridge bus translation.

    Let's also remove comments alluding to set_dma_addr which is not
    (and should not) be commonly used.

    Signed-off-by: Nicolas Pitre
    Signed-off-by: Russell King

    Nicolas Pitre
     
  • There is no machine class overriding this. If non linear translations
    are implemented again for some machines then this could be restored at
    that time.

    Signed-off-by: Nicolas Pitre
    Signed-off-by: Russell King

    Nicolas Pitre
     

07 Nov, 2008

1 commit

  • As of 73bdf0a60e607f4b8ecc5aec597105976565a84f, 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: Russell King

    Russell King
     

10 Oct, 2008

1 commit

  • 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: Nicolas Pitre
    Signed-off-by: Russell King

    Nicolas Pitre
     

01 Oct, 2008

1 commit


01 Sep, 2008

1 commit


10 Aug, 2008

1 commit

  • OMAP at least gets the return type(s) for the DMA translation functions
    wrong, which can lead to subtle errors. Avoid this by moving the DMA
    translation functions to asm/dma-mapping.h, and converting them to
    inline functions.

    Fix the OMAP DMA translation macros to use the correct argument and
    result types.

    Also, remove the unnecessary casts in dmabounce.c.

    Signed-off-by: Russell King

    Russell King
     

09 Aug, 2008

1 commit

  • 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: Lennert Buytenhek
    Tested-by: Riku Voipio

    Lennert Buytenhek
     

07 Aug, 2008

1 commit


03 Aug, 2008

1 commit