06 Dec, 2011

1 commit


21 Sep, 2011

2 commits


22 Jul, 2011

1 commit

  • Commit 66a625a (ARM: mm: proc-macros: Add generic proc/cache/tlb struct
    definition macros) introduced build errors when PM_SLEEP is not enabled.
    The per-CPU do_suspend/do_resume functions are defined via the
    preprocessor to constant 0. However, the macros which use these were
    converted to assembly, resulting in undefined references to these
    functions. Fix that by moving the ! ifdef section into proc-macros.S
    and deleting it from all effected proc-*.S files.

    Acked-by: Dave Martin
    Signed-off-by: Russell King

    Russell King
     

07 Jul, 2011

1 commit


28 Apr, 2011

1 commit


02 Apr, 2011

1 commit

  • CONFIG_PM is now set whenever we support either runtime PM in addition
    to suspend and hibernate. This causes build errors when runtime PM is
    enabled on a platform, but the CPU does not have the appropriate support
    for suspend.

    So, switch this code to use CONFIG_PM_SLEEP rather than CONFIG_PM to
    allow runtime PM to be enabled without causing build errors.

    Signed-off-by: Russell King

    Russell King
     

23 Feb, 2011

1 commit

  • This adds core support for saving and restoring CPU coprocessor
    registers for suspend/resume support. This contains support for suspend
    with ARM920, ARM926, SA11x0, PXA25x, PXA27x, PXA3xx, V6 and V7 CPUs.
    Tested on Assabet and Tegra 2.

    Tested-by: Colin Cross
    Tested-by: Kukjin Kim
    Signed-off-by: Russell King

    Russell King
     

22 Dec, 2010

1 commit


28 Oct, 2010

1 commit

  • Commit 81d11955bf0 ("ARM: 6405/1: Handle __flush_icache_all for
    CONFIG_SMP_ON_UP") added a new function to struct cpu_cache_fns:
    flush_icache_all(). It also implemented this for v6 and v7 but not
    for v5 and backwards. Without the function pointer in place, we
    will be calling wrong cache functions.

    For example with ep93xx we get following:

    Unable to handle kernel paging request at virtual address ee070f38
    pgd = c0004000
    [ee070f38] *pgd=00000000
    Internal error: Oops: 80000005 [#1] PREEMPT
    last sysfs file:
    Modules linked in:
    CPU: 0 Not tainted (2.6.36+ #1)
    PC is at 0xee070f38
    LR is at __dma_alloc+0x11c/0x2d0
    pc : [] lr : [] psr: 60000013
    sp : c581bde0 ip : 00000000 fp : c0472000
    r10: c0472000 r9 : 000000d0 r8 : 00020000
    r7 : 0001ffff r6 : 00000000 r5 : c0472400 r4 : c5980000
    r3 : c03ab7e0 r2 : 00000000 r1 : c59a0000 r0 : c5980000
    Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
    Control: c000717f Table: c0004000 DAC: 00000017
    Process swapper (pid: 1, stack limit = 0xc581a270)
    [] (__dma_alloc+0x11c/0x2d0)
    [] (dma_alloc_writecombine+0x1c/0x24)
    [] (ep93xx_pcm_preallocate_dma_buffer+0x44/0x60)
    [] (ep93xx_pcm_new+0x5c/0x88)
    [] (snd_soc_instantiate_cards+0x8a8/0xbc0)
    [] (soc_probe+0xfc/0x134)
    [] (platform_drv_probe+0x18/0x1c)
    [] (driver_probe_device+0xb0/0x16c)
    [] (bus_for_each_drv+0x48/0x84)
    [] (device_attach+0x50/0x68)
    [] (bus_probe_device+0x24/0x44)
    [] (device_add+0x2fc/0x44c)
    [] (platform_device_add+0x104/0x15c)
    [] (simone_init+0x60/0x94)
    [] (do_one_initcall+0xd0/0x1a4)

    __dma_alloc() calls (inlined) __dma_alloc_buffer() which ends up
    calling dmac_flush_range(). Now since the entries in the
    arm920_cache_fns are shifted by one, we jump into address 0xee070f38
    which is actually next instruction after the arm920_cache_fns
    structure.

    So implement flush_icache_all() for the rest of the supported CPUs
    using a generic 'invalidate I cache' instruction.

    Signed-off-by: Mika Westerberg
    Signed-off-by: Russell King

    Mika Westerberg
     

08 Oct, 2010

1 commit


27 Jul, 2010

1 commit

  • All implementations of cpu_proc_fin() start by disabling interrupts
    and then flush caches. Rather than have every processors proc_fin()
    implementation do this, move it out into generic code - and move the
    cache flush past setup_mm_for_reboot() (so it can benefit from having
    caches still enabled.)

    This allows cpu_proc_fin() to become independent of the L1/L2 cache
    types, and eventually move the L2 cache flushing into the L2 support
    code.

    Signed-off-by: Russell King

    Russell King
     

15 Feb, 2010

2 commits


14 Dec, 2009

1 commit


03 Oct, 2009

1 commit

  • Instruction fault status register, IFSR, was introduced on ARMv6 to
    provide status information about the last insturction fault. It
    needed for proper prefetch abort handling.

    Now we have three prefetch abort model:

    * legacy - for CPUs before ARMv6. They doesn't provide neither
    IFSR nor IFAR. We simulate IFSR with section translation fault
    status for them to generalize code;
    * ARMv6 - provides IFSR, but not IFAR;
    * ARMv7 - provides both IFSR and IFAR.

    Signed-off-by: Kirill A. Shutemov
    Signed-off-by: Russell King

    Kirill A. Shutemov
     

16 Sep, 2009

1 commit


01 Oct, 2008

6 commits


24 Apr, 2008

1 commit

  • The proc-*.S files have the _prefetch_abort pointer placed at the end
    of the processor structure but the cpu-multi32.h defines it in the
    second position. The patch also fixes the support for XSC3 and the
    MMU-less CPUs (740, 7tdmi, 940, 946 and 9tdmi).

    Signed-off-by: Catalin Marinas
    Signed-off-by: Russell King

    Catalin Marinas
     

19 Apr, 2008

1 commit

  • This patch adds a prefetch abort handler similar to the data abort one
    and renames the latter for consistency. Initial implementation by Paul
    Brook with some renaming by Catalin Marinas.

    Signed-off-by: Paul Brook
    Signed-off-by: Catalin Marinas

    Paul Brook
     

20 Mar, 2008

1 commit


22 Apr, 2007

1 commit


24 Jan, 2007

1 commit


13 Dec, 2006

1 commit

  • 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
     

04 Dec, 2006

1 commit

  • XScale cores either have a DSP coprocessor (which contains a single
    40 bit accumulator register), or an iWMMXt coprocessor (which contains
    eight 64 bit registers.)

    Because of the small amount of state in the DSP coprocessor, access to
    the DSP coprocessor (CP0) is always enabled, and DSP context switching
    is done unconditionally on every task switch. Access to the iWMMXt
    coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
    first issued, and iWMMXt context switching is done lazily.

    CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
    have iWMMXt support', but boards are supposed to select this config
    symbol by hand, and at least one pxa27x board doesn't get this right,
    so on that board, proc-xscale.S will incorrectly assume that we have a
    DSP coprocessor, enable CP0 on boot, and we will then only save the
    first iWMMXt register (wR0) on context switches, which is Bad.

    This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
    might have iWMMXt support, and we will enable iWMMXt context switching
    if it does.' This means that with this patch, running a CONFIG_IWMMXT=n
    kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
    state over context switches, and running a CONFIG_IWMMXT=y kernel on a
    non-iWMMXt capable CPU will still do DSP context save/restore.

    These changes should make iWMMXt work on PXA3xx, and as a side effect,
    enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
    as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
    as well as setting and using HWCAP_IWMMXT properly.

    Signed-off-by: Lennert Buytenhek
    Acked-by: Dan Williams
    Signed-off-by: Russell King

    Lennert Buytenhek
     

30 Nov, 2006

1 commit


03 Nov, 2006

1 commit

  • ARM patch 3756/1 added HWCAP_IWMMXT. This patch adds support
    for broadcasting that info via /proc/cpuinfo and sets it for
    the CPU features of the PXA270.

    I've booted 19rc3 on a pxa270 and confirmed that the /proc/cpuinfo
    shows "iwmmxt" in the Features.

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

    Paul Gortmaker
     

25 Sep, 2006

1 commit

  • On stepping A0/A1 of the 80200, invalidating D-cache by line doesn't
    clear the dirty bits, which means that if we invalidate a dirty line,
    the dirty data can still be written back to memory later on.

    To work around this, dma_inv_range() on these two processors is
    implemented as dma_flush_range() (i.e. do a clean D-cache line before
    doing the invalidate D-cache line.) For this, we currently have a
    processor ID check in xscale_dma_inv_range(), but a better solution
    is to add a separate cache_fns and proc_info for A0/A1 80200.

    Signed-off-by: Lennert Buytenhek
    Signed-off-by: Russell King

    Lennert Buytenhek
     

15 Sep, 2006

1 commit

  • Patch from Dan Williams

    commit a6a38a66224c7c578cfed2f584b440c81af0c3ae changed the iop321 id to a value that does not work with all platforms. Change the mask to permit bit 11. Tested on an iq80321 600Mhz CRB.

    Signed-off-by: Dan Williams
    Signed-off-by: Russell King

    Dan Williams
     

29 Jul, 2006

1 commit

  • Patch from Lennert Buytenhek

    The IOP 80219 xscale CPU is a stripped down version of the IOP32x.
    But the fact that the 80219 and IOP32x are very similar doesn't mean
    that they need to share a cpu table entry. It's also somewhat confusing
    for the end user to see the 80219 reported as an IOP32x, so this patch
    splits the IOP32x cpu table entry to make a separate entry for the
    80219.

    Signed-off-by: Lennert Buytenhek
    Signed-off-by: Dan Williams
    Signed-off-by: Russell King

    Lennert Buytenhek
     

02 Jul, 2006

2 commits


30 Jun, 2006

1 commit

  • On some CPUs, bit 4 of section mappings means "update the
    cache when written to". On others, this bit is required to
    be one, and others it's required to be zero. Finally, on
    ARMv6 and above, setting it turns on "no execute" and prevents
    speculative prefetches.

    With all these combinations, no one value fits all CPUs, so we
    have to pick a value depending on the CPU type, and the area
    we're mapping.

    Signed-off-by: Russell King

    Russell King
     

29 Jun, 2006

1 commit

  • Most MMU-based CPUs have a restriction on the setting of the data cache
    enable and mmu enable bits in the control register, whereby if the data
    cache is enabled, the MMU must also be enabled. Enabling the data
    cache without the MMU is an invalid combination.

    However, there are CPUs where the data cache can be enabled without the
    MMU.

    In order to allow these CPUs to take advantage of that, provide a
    method whereby each proc-*.S file defines the control regsiter value
    for use with nommu (with the MMU disabled.) Later on, when we add
    support for enabling the MMU on these devices, we can adjust the
    "crval" macro to also enable the data cache for nommu.

    Signed-off-by: Russell King

    Russell King
     

26 Mar, 2006

1 commit