aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-arm/cacheflush.h
Commit message (Collapse)AuthorAge
* [ARM] Use CPU_CACHE_* where possible in asm/cacheflush.hRussell King2006-09-27
| | | | | | | | Three of the generic cache method options were using explicit CPU types, whereas they could use the CPU_CACHE_* definitions instead. Switch them over to use the CPU_CACHE_* definitions. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM946E-S core supportHyok S. Choi2006-09-27
| | | | | | | | | | | This patch adds ARM946E-S core support which has typically 8KB I&D cache. It has a MPU and supports ARMv5TE instruction set. Because the ARM946E-S core can be synthesizable with various cache size, CONFIG_CPU_DCACHE_SIZE is defined for vendor specific configurations. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM940T core supportHyok S. Choi2006-09-27
| | | | | | | | This patch adds ARM940T core support which has 4KB D-cache, 4KB I-cache and a MPU. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM9TDMI core supportHyok S. Choi2006-09-27
| | | | | | | | This patch adds ARM9TDMI core support which has no cache and no CP15 register(no memory control unit). Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM740T core supportHyok S. Choi2006-09-27
| | | | | | | This patch adds ARM740T core support which has a MPU and 4KB or 8KB cache. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] nommu: add ARM7TDMI core supportHyok S. Choi2006-09-27
| | | | | | | | This patch adds ARM7TDMI core support which has no cache and no CP15 register(no memory control unit). Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] 3762/1: Fix ptrace cache coherency bug for ARM1136 VIPT nonaliasing ↵George G. Davis2006-09-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Harvard caches Patch from George G. Davis Resolve ARM1136 VIPT non-aliasing cache coherency issues observed when using ptrace to set breakpoints and cleanup copy_{to,from}_user_page() while we're here as requested by Russell King because "it's also far too heavy on non-v6 CPUs". NOTES: 1. Only access_process_vm() calls copy_{to,from}_user_page(). 2. access_process_vm() calls get_user_pages() to pin down the "page". 3. get_user_pages() calls flush_dcache_page(page) which ensures cache coherency between kernel and userspace mappings of "page". However flush_dcache_page(page) may not invalidate I-Cache over this range for all cases, specifically, I-Cache is not invalidated for the VIPT non-aliasing case. So memory is consistent between kernel and user space mappings of "page" but I-Cache may still be hot over this range. IOW, we don't have to worry about flush_cache_page() before memcpy(). 4. Now, for the copy_to_user_page() case, after memcpy(), we must flush the caches so memory is consistent with kernel cache entries and invalidate the I-Cache if this mm region is executable. We don't need to do anything after memcpy() for the copy_from_user_page() case since kernel cache entries will be invalidated via the same process above if we access "page" again. The flush_ptrace_access() function (borrowed from SPARC64 implementation) is added to handle cache flushing after memcpy() for the copy_to_user_page() case. Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Don't include linux/config.h from anywhere else in include/David Woodhouse2006-04-26
| | | | Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* [ARM] 3377/2: add support for intel xsc3 coreLennert Buytenhek2006-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch from Lennert Buytenhek This patch adds support for the new XScale v3 core. This is an ARMv5 ISA core with the following additions: - L2 cache - I/O coherency support (on select chipsets) - Low-Locality Reference cache attributes (replaces mini-cache) - Supersections (v6 compatible) - 36-bit addressing (v6 compatible) - Single instruction cache line clean/invalidate - LRU cache replacement (vs round-robin) I attempted to merge the XSC3 support into proc-xscale.S, but XSC3 cores have separate errata and have to handle things like L2, so it is simpler to keep it separate. L2 cache support is currently a build option because the L2 enable bit must be set before we enable the MMU and there is no easy way to capture command line parameters at this point. There are still optimizations that can be done such as using LLR for copypage (in theory using the exisiting mini-cache code) but those can be addressed down the road. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Cleanup ARM includesRussell King2006-01-03
| | | | | | | | | | | | | | | | arch/arm/kernel/entry-armv.S has contained a comment suggesting that asm/hardware.h and asm/arch/irqs.h should be moved into the asm/arch/entry-macro.S include. So move the includes to these two files as required. Add missing includes (asm/hardware.h, asm/io.h) to asm/arch/system.h includes which use those facilities, and remove asm/io.h from kernel/process.c. Remove other unnecessary includes from arch/arm/kernel, arch/arm/mm and arch/arm/mach-footbridge. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Fix ARMv6 VIPT cache >= 32KRussell King2005-09-08
| | | | | | | This adds the necessary changes to ensure that we flush the caches correctly with aliasing VIPT caches. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] ARM: Add common CACHE_COLOUR macroRussell King2005-06-20
| | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
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!