Eric Lee / smarc-fsl-linux-kernel

29 Jun, 2012

1 commit

30 Mar, 2012

1 commit

  • 820d41cf0   Merge tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc ... Browse Code »

    Pull "ARM: cleanups of io includes" from Olof Johansson:
    "Rob Herring has done a sweeping change cleaning up all of the
    mach/io.h includes, moving some of the oft-repeated macros to a common
    location and removing a bunch of boiler plate. This is another step
    closer to a common zImage for multiple platforms."

    Fix up various fairly trivial conflicts ( removal vs changes
    around it, tegra localtimer.o is *still* gone, yadda-yadda).

    * tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (29 commits)
    ARM: tegra: Include assembler.h in sleep.S to fix build break
    ARM: pxa: use common IOMEM definition
    ARM: dma-mapping: convert ARCH_HAS_DMA_SET_COHERENT_MASK to kconfig symbol
    ARM: __io abuse cleanup
    ARM: create a common IOMEM definition
    ARM: iop13xx: fix missing declaration of iop13xx_init_early
    ARM: fix ioremap/iounmap for !CONFIG_MMU
    ARM: kill off __mem_pci
    ARM: remove bunch of now unused mach/io.h files
    ARM: make mach/io.h include optional
    ARM: clps711x: remove unneeded include of mach/io.h
    ARM: dove: add explicit include of dove.h to addr-map.c
    ARM: at91: add explicit include of hardware.h to uncompressor
    ARM: ep93xx: clean-up mach/io.h
    ARM: tegra: clean-up mach/io.h
    ARM: orion5x: clean-up mach/io.h
    ARM: davinci: remove unneeded mach/io.h include
    [media] davinci: remove includes of mach/io.h
    ARM: OMAP: Remove remaining includes for mach/io.h
    ARM: msm: clean-up mach/io.h
    ...

    Linus Torvalds
     

29 Mar, 2012

2 commits

07 Mar, 2012

1 commit

  • 4fe7ef3a0   ARM: provide runtime hook for ioremap/iounmap ... Browse Code »
    43

    We have compile time over-ride of ioremap and iounmap, but an run-time
    override is needed for multi-platform builds. This adds an extra function
    pointer check, but ioremap is not peformance critical. The option for
    compile time selection remains.

    The caller variant is used here to provide correct caller information as
    ARM can only support level 0 for __builtin_return_address.

    Signed-off-by: Rob Herring
    Cc: Russell King
    Reviewed-by: Arnd Bergmann
    Reviewed-by: Nicolas Pitre

    Rob Herring
     

03 Feb, 2012

1 commit

  • 97f104098   Revert "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping" ... Browse Code »

    This reverts commit 3c424f359898aff48c3d5bed608ac706f8a528c3.

    Joachim Eastwood reports:
    | "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
    | Commit: 3c424f359898aff48c3d5bed608ac706f8a528c3 in Linus master
    |
    | Breaks booting on my custom AT91RM9200 board.
    | There isn't any error messages or anything that indicates what goes
    | wrong it just stops after; Uncompressing Linux... done, booting the
    | kernel.
    |
    | Reverting it makes my board boot again.

    and further debugging reveals:

    ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
    ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
    ioremap: found: addr fef74000 => fed73000 => fed73400

    Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
    0xfffff. This happens because the changed if statement becomes:

    if (0x00200 > 0xfffff ||
    0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
    and therefore:
    if (0x00200 > 0xfffff ||
    0x000003ff > 0x00203fff)

    The if condition fails, and so we _believe_ that the SRAM mapping fits
    our request. Clearly that's totally bogus.

    Moreover, the original premise of the 'fix' patch was wrong:
    | The condition checking boundaries of the requested and existing
    | mappings didn't take in-page offset into consideration though,
    | which lead to obscure and hard to debug problems when requested
    | mapping crossed end of the static one.

    as the code immediately above this loop does:

    size = PAGE_ALIGN(offset + size);

    so 'size' already contains the requested offset into the page.

    So, revert the broken 'fix'.

    Acked-by: Nicolas Pitre

    Russell King
     

28 Jan, 2012

1 commit

  • 3c424f359   ARM: 7304/1: ioremap: fix boundary check when reusing static mapping ... Browse Code »
    86

    Since commit 576d2f2525612ecb5af029a76f21f22a3b82563d "ARM: add
    generic ioremap optimization by reusing static mappings" ioremap()
    is trying to reuse existing static mapping when possible.

    The condition checking boundaries of the requested and existing
    mappings didn't take in-page offset into consideration though,
    which lead to obscure and hard to debug problems when requested
    mapping crossed end of the static one.

    Signed-off-by: Pawel Moll
    Acked-by: Nicolas Pitre
    Signed-off-by: Russell King

    Pawel Moll
     

09 Dec, 2011

1 commit

08 Dec, 2011

2 commits

  • da0287798   ARM: LPAE: Page table maintenance for the 3-level format ... Browse Code »

    This patch modifies the pgd/pmd/pte manipulation functions to support
    the 3-level page table format. Since there is no need for an 'ext'
    argument to cpu_set_pte_ext(), this patch conditionally defines a
    different prototype for this function when CONFIG_ARM_LPAE.

    The patch also introduces the L_PGD_SWAPPER flag to mark pgd entries
    pointing to pmd tables pre-allocated in the swapper_pg_dir and avoid
    trying to free them at run-time. This flag is 0 with the classic page
    table format.

    Signed-off-by: Catalin Marinas

    Catalin Marinas
     
  • 03a6b8274   ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud ... Browse Code »

    With the arch/arm code conversion to pgtable-nopud.h, the section and
    supersection (un|re)map code triggers compiler warnings on UP systems.
    This is caused by pmd_offset() being given a pgd_t argument rather than
    a pud_t one. This patch makes the necessary conversion with the
    assumption that the pud is folded into the pgd. The page table setting
    code only loops over the pmd which is enough with the classic page
    tables. This code is not compiled when LPAE is enabled.

    Signed-off-by: Catalin Marinas

    Catalin Marinas
     

27 Nov, 2011

2 commits

  • 576d2f252   ARM: add generic ioremap optimization by reusing static mappings ... Browse Code »
    43

    Now that we have all the static mappings from iotable_init() located
    in the vmalloc area, it is trivial to optimize ioremap by reusing those
    static mappings when the requested physical area fits in one of them,
    and so in a generic way for all platforms.

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

    Nicolas Pitre
     
  • 6ee723a65   ARM: simplify __iounmap() when dealing with section based mapping ... Browse Code »

    Firstly, there is no need to have a double pointer here as we're only
    walking the vmlist and not modifying it.

    Secondly, for the same reason, we don't need a write lock but only a
    read lock here, since the lock only protects the coherency of the list
    nothing else.

    Lastly, the reason for holding a lock is not what the comment says, so
    let's remove that misleading piece of information.

    Signed-off-by: Nicolas Pitre

    Nicolas Pitre
     

23 Oct, 2011

1 commit

24 Dec, 2010

1 commit

13 Oct, 2010

1 commit

27 Jul, 2010

1 commit

22 Jun, 2010

1 commit

  • 309caa9cc   ARM: Prohibit ioremap() on kernel managed RAM ... Browse Code »

    ARMv6 and above have a restriction whereby aliasing virtual:physical
    mappings must not have differing memory type and sharability
    attributes. Strictly, this covers the memory type (strongly ordered,
    device, memory), cache attributes (uncached, write combine, write
    through, write back read alloc, write back write alloc) and the
    shared bit.

    However, using ioremap() and its variants on system RAM results in
    mappings which differ in these attributes from the main system RAM
    mapping. Other architectures which similar restrictions approch this
    problem in the same way - they do not permit ioremap on main system
    RAM.

    Make ARM behave in the same way, with a WARN_ON() such that users can
    be traced and an alternative approach found.

    Signed-off-by: Russell King

    Russell King
     

16 Feb, 2010

1 commit

  • 31aa8fd6f   ARM: Add caller information to ioremap ... Browse Code »

    This allows the procfs vmallocinfo file to show who created the ioremap
    regions. Note: __builtin_return_address(0) doesn't do what's expected
    if its used in an inline function, so we leave __arm_ioremap callers
    in such places alone.

    Signed-off-by: Russell King

    Russell King
     

19 May, 2009

1 commit

  • 69d3a84a6   omap iommu: simple virtual address space management ... Browse Code »

    This patch provides a device drivers, which has a omap iommu, with
    address mapping APIs between device virtual address(iommu), physical
    address and MPU virtual address.

    There are 4 possible patterns for iommu virtual address(iova/da) mapping.

    |iova/ mapping iommu_ page
    | da pa va (d)-(p)-(v) function type
    ---------------------------------------------------------------------------
    1 | c c c 1 - 1 - 1 _kmap() / _kunmap() s
    2 | c c,a c 1 - 1 - 1 _kmalloc()/ _kfree() s
    3 | c d c 1 - n - 1 _vmap() / _vunmap() s
    4 | c d,a c 1 - n - 1 _vmalloc()/ _vfree() n*

    'iova': device iommu virtual address
    'da': alias of 'iova'
    'pa': physical address
    'va': mpu virtual address

    'c': contiguous memory area
    'd': dicontiguous memory area
    'a': anonymous memory allocation
    '()': optional feature

    'n': a normal page(4KB) size is used.
    's': multiple iommu superpage(16MB, 1MB, 64KB, 4KB) size is used.

    '*': not yet, but feasible.

    Signed-off-by: Hiroshi DOYU

    Hiroshi DOYU
     

26 Jan, 2009

1 commit

  • 24f11ec00   [ARM] fix section-based ioremap ... Browse Code »

    Tomi Valkeinen reports:
    Running with latest linux-omap kernel on OMAP3 SDP board, I have
    problem with iounmap(). It looks like iounmap() does not properly
    free large areas. Below is a test which fails for me in 6-7 loops.

    for (i = 0; i < 200; ++i) {
    vaddr = ioremap(paddr, size);
    if (!vaddr) {
    printk("couldn't ioremap\n");
    break;
    }
    iounmap(vaddr);
    }

    The changes to vmalloc.c weren't reflected in the ARM ioremap
    implementation. Turns out the fix is rather simple.

    Tested-by: Tomi Valkeinen
    Tested-by: Matt Gerassimoff
    Signed-off-by: Russell King

    Russell King
     

10 Oct, 2008

1 commit

01 Oct, 2008

1 commit

06 Sep, 2008

1 commit

05 Sep, 2008

1 commit

  • 09d9bae06   [ARM] sparse: fix several warnings ... Browse Code »

    arch/arm/kernel/process.c:270:6: warning: symbol 'show_fpregs' was not declared. Should it be static?

    This function isn't used, so can be removed.

    arch/arm/kernel/setup.c:532:9: warning: symbol 'len' shadows an earlier one
    arch/arm/kernel/setup.c:524:6: originally declared here

    A function containing two 'len's.

    arch/arm/mm/fault-armv.c:188:13: warning: symbol 'check_writebuffer_bugs' was not declared. Should it be static?
    arch/arm/mm/mmap.c:122:5: warning: symbol 'valid_phys_addr_range' was not declared. Should it be static?
    arch/arm/mm/mmap.c:137:5: warning: symbol 'valid_mmap_phys_addr_range' was not declared. Should it be static?

    Missing includes.

    arch/arm/kernel/traps.c:71:77: warning: Using plain integer as NULL pointer
    arch/arm/mm/ioremap.c:355:46: error: incompatible types in comparison expression (different address spaces)

    Sillies.

    Signed-off-by: Russell King

    Russell King
     

01 Sep, 2008

1 commit

03 Aug, 2008

1 commit

06 Feb, 2008

1 commit

  • 5e5419734   add mm argument to pte/pmd/pud/pgd_free ... Browse Code »

    (with Martin Schwidefsky )

    The pgd/pud/pmd/pte page table allocation functions get a mm_struct pointer as
    first argument. The free functions do not get the mm_struct argument. This
    is 1) asymmetrical and 2) to do mm related page table allocations the mm
    argument is needed on the free function as well.

    [kamalesh@linux.vnet.ibm.com: i386 fix]
    [akpm@linux-foundation.org: coding-syle fixes]
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Martin Schwidefsky
    Cc:
    Signed-off-by: Kamalesh Babulal
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     

12 Jul, 2007

1 commit

21 May, 2007

1 commit

06 May, 2007

1 commit

  • 3603ab2b6   [ARM] mm 10: allow memory type to be specified with ioremap ... Browse Code »

    __ioremap() took a set of page table flags (specifically the cacheable
    and bufferable bits) to control the mapping type. However, with
    the advent of ARMv6, this is far too limited.

    Replace the page table flags with a memory type index, so that the
    desired attributes can be selected from the mem_type table.

    Finally, to prevent silent miscompilation due to the differing
    arguments, rename the __ioremap() and __ioremap_pfn() functions.

    Signed-off-by: Russell King

    Russell King
     

22 Apr, 2007

3 commits

  • c172cc92c   [ARM] mm 6: allow mem_types table to specify extended pte attributes ... Browse Code »

    Add prot_pte_ext to the mem_types table to allow the extended pte
    attributes to be passed to set_pte_ext(), thereby permitting us to
    specify memory type information for the hardware PTE entries.

    Signed-off-by: Russell King

    Russell King
     
  • b29e9f5e6   [ARM] mm 5: Use mem_types table in ioremap ... Browse Code »

    We really want to be using the memory type table in ioremap, so we
    only have to do the CPU type fixups in one place.

    Signed-off-by: Russell King

    Russell King
     
  • 4a56c1e41   [ARM] mm 3: separate out supersection mappings, avoid for <4GB ... Browse Code »

    Catalin Marinas at ARM Ltd says:
    > The CPU architects in ARM intended supersections only as a way to map
    > addresses >= 4GB. Supersections are not mandated by the architecture
    > and there is no easy way to detect their hardware support at run-time
    > (other than checking for a specific core). From the analysis done in
    > ARM, there wasn't a clear performance gain by using supersections
    > rather than sections (no significant improvement in the TLB misses).

    Therefore, we should avoid using supersections unless there's a real
    need (iow, we're mapping addresses >= 4GB).

    This means that we can simplify create_mapping() a bit since we will
    only use supersection mappings for addresses >= 4GB, which means that
    the physical, virtual and length must be multiples of the supersection
    mapping size.

    Signed-off-by: Russell King

    Russell King
     

26 Jan, 2007

1 commit

18 Dec, 2006

1 commit

13 Dec, 2006

2 commits

  • da2c12a27   [ARM] Clean up ioremap code ... Browse Code »

    Since we're keeping the ioremap code, we might as well keep it as
    close to the standard kernel as possible.

    Signed-off-by: Russell King

    Russell King
     
  • ad1ae2fe7   [ARM] Unuse another Linux PTE bit ... Browse Code »

    L_PTE_ASID is not really required to be stored in every PTE, since we
    can identify it via the address passed to set_pte_at(). So, create
    set_pte_ext() which takes the address of the PTE to set, the Linux
    PTE value, and the additional CPU PTE bits which aren't encoded in
    the Linux PTE value.

    Signed-off-by: Russell King

    Russell King
     

09 Oct, 2006

1 commit

26 Sep, 2006

1 commit

  • 46a82b2d5   [PATCH] Standardize pxx_page macros ... Browse Code »

    One of the changes necessary for shared page tables is to standardize the
    pxx_page macros. pte_page and pmd_page have always returned the struct
    page associated with their entry, while pte_page_kernel and pmd_page_kernel
    have returned the kernel virtual address. pud_page and pgd_page, on the
    other hand, return the kernel virtual address.

    Shared page tables needs pud_page and pgd_page to return the actual page
    structures. There are very few actual users of these functions, so it is
    simple to standardize their usage.

    Since this is basic cleanup, I am submitting these changes as a standalone
    patch. Per Hugh Dickins' comments about it, I am also changing the
    pxx_page_kernel macros to pxx_page_vaddr to clarify their meaning.

    Signed-off-by: Dave McCracken
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave McCracken
     

29 Jul, 2006

1 commit