aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/mm/cache-feroceon-l2.c
AgeCommit message (Collapse)Author
2014-05-22ARM: l2c: remove outer_inv_all() methodRussell King
No one ever calls this function anywhere in the kernel, so let's completely remove it from the outer cache API and turn it into an internal-only thing. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-04-05Merge tag 'soc-3.15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC specific changes from Arnd Bergmann: "Lots of changes specific to one of the SoC families. Some that stick out are: - mach-qcom gains new features, most importantly SMP support for the newer chips (Stephen Boyd, Rohit Vaswani) - mvebu gains support for three new SoCs: Armada 375, 380 and 385 (Thomas Petazzoni and Free-electrons team) - SMP support for Rockchips (Heiko Stübner) - Lots of i.MX changes (Shawn Guo) - Added support for BCM5301x SoC (Hauke Mehrtens) - Multiplatform support for Marvell Kirkwood and Dove (Andrew Lunn and Sebastian Hesselbarth doing the final part of a long journey) - Unify davinci platforms and remove obsolete ones (Sekhar Nori, Arnd Bergmann)" * tag 'soc-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (126 commits) ARM: sunxi: Select HAVE_ARM_ARCH_TIMER ARM: cache-tauros2: remove ARMv6 code ARM: mvebu: don't select CONFIG_NEON ARM: davinci: fix DT booting with default defconfig ARM: configs: bcm_defconfig: enable bcm590xx regulator support ARM: davinci: remove tnetv107x support MAINTAINERS: Update ARM STi maintainers ARM: restrict BCM_KONA_UART to ARCH_BCM_MOBILE ARM: bcm21664: Add board support. ARM: sunxi: Add the new watchog compatibles to the reboot code ARM: enable ARM_HAS_SG_CHAIN for multiplatform ARM: davinci: remove da8xx_omapl_defconfig ARM: davinci: da8xx: fix multiple watchdog device registration ARM: davinci: add da8xx specific configs to davinci_all_defconfig ARM: davinci: enable da8xx build concurrently with older devices ARM: BCM5301X: workaround suppress fault ARM: BCM5301X: add early debugging support ARM: BCM5301X: initial support for the BCM5301X/BCM470X SoCs with ARM CPU ARM: mach-bcm: Remove GENERIC_TIME ARM: shmobile: APMU: Fix warnings due to improper printk formats ...
2014-02-22ARM: MM: Add DT binding for Feroceon L2 cacheAndrew Lunn
Instantiate the L2 cache from DT. Indicate in DT where the cache control register is so that it is possible to enable/disable write through on the CPU. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-02-22ARM: orion: Move cache-feroceon-l2.h out of plat-orionAndrew Lunn
With the gradual move to DT, kirkwood has become a lot less dependent on plat-orion. cache-feroceon-l2.h is the last dependency. Move it out so we can drop plat-orion when building DT only kirkwood boards. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-02-10ARM: 7949/1: feroceon: Log a FW_BUG if the L2 cache is turned on at bootJason Gunthorpe
Booting on feroceon CPUS requires the L2 cache to be turned off. With some kernel configurations (notably CONFIG_ARM_PATCH_PHYS_VIRT disabled) the kernel will boot even if the L2 is turned on. However there may be subtle breakage, and when PATCH_PHYS_VIRT is enabled it is very likely that booting with L2 will crash at early boot before any kernel diagnostic output. The diagnostic message is intended to discourage people from shipping bootloaders that leave the L2 turned on. The issue on feroceon is that the L2 is bypassed when the L1 caches are disabled. So the decompressor will place parts of the kernel image into the L2 and the early cache-off boot code in head.S will write to parts of the kernel image, bypassing the L2 and creating inconsistency. Tested on ARM Kirkwood. Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-04-17ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for FeroceonIllia Ragozin
On Feroceon the L2 cache becomes non-coherent with the CPU when the L1 caches are disabled. Thus the L2 needs to be invalidated after both L1 caches are disabled. On kexec before the starting the code for relocation the kernel, the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon), but after L2 cache is never invalidated, because inv_all is not set in cache-feroceon-l2.c. So kernel relocation and decompression may has (and usually has) errors. Setting the function enables L2 invalidation and fixes the issue. Cc: <stable@vger.kernel.org> Signed-off-by: Illia Ragozin <illia.ragozin@grapecom.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-03-28ARM: move CP15 definitions to separate header fileRussell King
Avoid namespace conflicts with drivers over the CP15 definitions by moving CP15 related prototypes and definitions to a private header file. Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> [Tegra] Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com> [EP93xx] Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David Howells <dhowells@redhat.com>
2010-12-19ARM: fix cache-feroceon-l2 after stack based kmap_atomic()Nicolas Pitre
Since commit 3e4d3af501 "mm: stack based kmap_atomic()", it is actively wrong to rely on fixed kmap type indices (namely KM_L2_CACHE) as kmap_atomic() totally ignores them and a concurrent instance of it may happily reuse any slot for any purpose. Because kmap_atomic() is now able to deal with reentrancy, we can get rid of the ad hoc mapping here. While the code is made much simpler, there is a needless cache flush introduced by the usage of __kunmap_atomic(). It is not clear if the performance difference to remove that is worth the cost in code maintenance (I don't think there are that many highmem users on that platform anyway) but that should be reconsidered when/if someone cares enough to do some measurements. Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
2009-03-28[ARM] Kirkwood: small L2 code cleanupNicolas Pitre
Strictly speaking, a MCR instruction does not produce any output. Signed-off-by: Nicolas Pitre <nico@marvell.com>
2009-03-28[ARM] Kirkwood: invalidate L2 cache before enabling itMaxime Bizon
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-15[ARM] Feroceon: add highmem support to L2 cache handling codeNicolas Pitre
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-08[ARM] 5329/1: Feroceon: fix feroceon_l2_inv_rangeNicolas Pitre
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 Pitre
- 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 Buytenhek
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-22[ARM] Feroceon: L2 cache supportLennert Buytenhek
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>