summaryrefslogtreecommitdiff
path: root/arch/arm/mm/cache-feroceon-l2.c
AgeCommit message (Collapse)AuthorFilesLines
2009-03-29[ARM] Kirkwood: small L2 code cleanupNicolas Pitre1-3/+1
Strictly speaking, a MCR instruction does not produce any output. Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-03-29[ARM] Kirkwood: invalidate L2 cache before enabling itMaxime Bizon1-0/+5
I get random oopses on my Kirkwood board at startup when L2 cache is enabled. FYI I'm using Marvell uboot version 3.4.16 Each boot produces the same oops, but anything that changes the kernel size (even only changing initramfs) makes the oops different. I noticed that nothing invalidates the L2 cache before enabling it, doing so fixes my problem. Signed-off-by: Maxime Bizon <mbizon@freebox.fr> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-03-16[ARM] Feroceon: add highmem support to L2 cache handling codeNicolas Pitre1-17/+37
The choice is between looping over the physical range and performing single cache line operations, or to map highmem pages somewhere, as cache range ops are possible only on virtual addresses. Because L2 range ops are much faster, we go with the later by factoring the physical-to-virtual address conversion and use a fixmap entry for it in the HIGHMEM case. Possible future optimizations to avoid the pte setup cost: - do the pte setup for highmem pages only - determine a threshold for doing a line-by-line processing on physical addresses when the range is small Signed-off-by: Nicolas Pitre <nico@marvell.com>
2008-11-09[ARM] 5329/1: Feroceon: fix feroceon_l2_inv_rangeNicolas Pitre1-2/+2
Same fix as commit c7cf72dcadb: when 'start' and 'end' are less than a cacheline apart and 'start' is unaligned we are done after cleaning and invalidating the first cacheline. Cc: <stable@kernel.org> Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-30[ARM] Feroceon: small cleanups to L2 cache codeNicolas Pitre1-17/+25
- Make sure that coprocessor instructions for range ops are contiguous and not reordered. - s/invalidate_and_disable_dcache/flush_and_disable_dcache/ - Don't re-enable I/D caches if they were not enabled initially. - Change some masks to shifts for better generated code. Signed-off-by: Nicolas Pitre <nico@marvell.com> Acked-by: Lennert Buytenhek <buytenh@marvell.com>
2008-08-09[ARM] Move include/asm-arm/plat-orion to arch/arm/plat-orion/include/platLennert Buytenhek1-1/+1
This patch performs the equivalent include directory shuffle for plat-orion, and fixes up all users. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-06-23[ARM] Feroceon: L2 cache supportLennert Buytenhek1-0/+318
This patch adds support for the unified Feroceon L2 cache controller as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo families of ARM SoCs. Note that: - Page table walks are outer uncacheable on Kirkwood and Discovery Duo, since the ARMv5 spec provides no way to indicate outer cacheability of page table walks (specifying it in TTBR[4:3] is an ARMv6+ feature). This requires adding L2 cache clean instructions to proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled by defining a new TLB type (TLB_FEROCEON) which is almost identical to the v4wbi one but provides a TLB_L2CLEAN_FR flag. - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2 range by MVA' and 'invalidate L2 range by MVA') operations, and this patch uses those range operations for all Linux outer cache operations, as they are faster than the regular per-line operations. L2 range operations are not interruptible on this hardware, which avoids potential livelock issues, but can be bad for interrupt latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which allows you to select the maximum range size to operate on at once. (Valid range is between one cache line and one 4KiB page, and must be a multiple of the line size.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>