Eric Lee / smarc-fsl-linux-kernel

27 Nov, 2011

1 commit

  • 0536bdf33   ARM: move iotable mappings within the vmalloc region ... Browse Code »
    86

    In order to remove the build time variation between different SOCs with
    regards to VMALLOC_END, the iotable mappings are now allocated inside
    the vmalloc region. This allows for VMALLOC_END to be identical across
    all machines.

    The value for VMALLOC_END is now set to 0xff000000 which is right where
    the consistent DMA area starts.

    To accommodate all static mappings on machines with possible highmem usage,
    the default vmalloc area size is changed to 240 MB so that VMALLOC_START
    is no higher than 0xf0000000 by default.

    Signed-off-by: Nicolas Pitre
    Tested-by: Stephen Warren
    Tested-by: Kevin Hilman
    Tested-by: Jamie Iles

    Nicolas Pitre
     

27 Jul, 2010

1 commit

  • 1dbd30e98   ARM: 6225/1: make TCM allocation static and common for all archs ... Browse Code »

    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 Feb, 2010

1 commit

30 Jul, 2009

1 commit

16 Mar, 2009

1 commit

  • 5f0fbf9ec   [ARM] fixmap support ... Browse Code »

    This is the minimum fixmap interface expected to be implemented by
    architectures supporting highmem.

    We have a second level page table already allocated and covering
    0xfff00000-0xffffffff because the exception vector page is located
    at 0xffff0000, and various cache tricks already use some entries above
    0xffff0000. Therefore the PTEs covering 0xfff00000-0xfffeffff are free
    to be used.

    However the XScale cache flushing code already uses virtual addresses
    between 0xfffe0000 and 0xfffeffff.

    So this reserves the 0xfff00000-0xfffdffff range for fixmap stuff.

    The Documentation/arm/memory.txt information is updated accordingly,
    including the information about the actual top of DMA memory mapping
    region which didn't match the code.

    Signed-off-by: Nicolas Pitre

    Nicolas Pitre
     

18 Nov, 2005

1 commit

  • 02b308392   [ARM] Fix some corner cases in new mm initialisation ... Browse Code »

    Document that the VMALLOC_END address must be aligned to 2MB since
    it must align with a PGD boundary.

    Allocate the vectors page early so that the flush_cache_all() later
    will cause any dirty cache lines in the direct mapping will be safely
    written back.

    Move the flush_cache_all() to the second local_flush_cache_tlb() and
    remove the now redundant first local_flush_cache_tlb().

    Signed-off-by: Russell King

    Russell King
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds