iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
15ce92861f
linux/arch/m68k/include/asm/cacheflush_no.h

80 lines
2.2 KiB
C
Raw Normal View History

Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
#ifndef _M68KNOMMU_CACHEFLUSH_H
#define _M68KNOMMU_CACHEFLUSH_H
/*
m68knommu: clean up ColdFire cache control code The cache control code for the ColdFire CPU's is a big ugly mess of "#ifdef"ery liberally coated with bit constants. Clean it up. The cache controllers in the various ColdFire parts are actually quite similar. Just differing in some bit flags and options supported. Using the header defines now in place it is pretty easy to factor out the small differences and use common setup and flush/invalidate code. I have preserved the cache setups as they where in the old code (except where obviously wrong - like in the case of the 5249). Following from this it should be easy now to extend the possible setups used on the CACHE controllers that support split cacheing or copy-back or write through options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-09 06:35:55 +03:00
* (C) Copyright 2000-2010, Greg Ungerer <gerg@snapgear.com>
Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
*/
#include <linux/mm.h>
m68knommu: move inclusion of ColdFire v4 cache registers Move the inclusion of the version 4 cache controller registers so that it is with all the other register bit flag definitions. This makes it consistent with the other version core inclusion points, and means we don't need "#ifdef"ery in odd-ball places for these definitions. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-09 03:40:44 +03:00
#include <asm/mcfsim.h>
Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
#define flush_cache_all() __flush_cache_all()
#define flush_cache_mm(mm) do { } while (0)
[PATCH] Optimize D-cache alias handling on fork Virtually index, physically tagged cache architectures can get away without cache flushing when forking. This patch adds a new cache flushing function flush_cache_dup_mm(struct mm_struct *) which for the moment I've implemented to do the same thing on all architectures except on MIPS where it's a no-op. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-12 20:14:57 +03:00
#define flush_cache_dup_mm(mm) do { } while (0)
m68knommu: clean up ColdFire cache control code The cache control code for the ColdFire CPU's is a big ugly mess of "#ifdef"ery liberally coated with bit constants. Clean it up. The cache controllers in the various ColdFire parts are actually quite similar. Just differing in some bit flags and options supported. Using the header defines now in place it is pretty easy to factor out the small differences and use common setup and flush/invalidate code. I have preserved the cache setups as they where in the old code (except where obviously wrong - like in the case of the 5249). Following from this it should be easy now to extend the possible setups used on the CACHE controllers that support split cacheing or copy-back or write through options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-09 06:35:55 +03:00
#define flush_cache_range(vma, start, end) do { } while (0)
[PATCH] m68knommu: fix cache actions for ColdFire 5249, 527x and 528x processors Add better support for flushing the cache's on some ColdFire processors. The 5249 cache code is now enabled (it was stubbed out), it really is needed. Add support for the 527x and 528x families - we only use the simple instruction cache on them. Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-13 05:14:08 +04:00
#define flush_cache_page(vma, vmaddr) do { } while (0)
m68knommu: create optimal separate instruction and data cache for ColdFire Create separate functions to deal with instruction and data cache flushing. This way we can optimize them for the vairous cache types and arrangements used across the ColdFire family. For example the unified caches in the version 3 cores means we don't need to flush the instruction cache. For the version 2 cores that do not do data cacheing (or where we choose instruction cache only) we don't need to do any data flushing. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-10 08:22:19 +03:00
#define flush_dcache_range(start, len) __flush_dcache_all()
block: add helpers to run flush_dcache_page() against a bio and a request's pages Mtdblock driver doesn't call flush_dcache_page for pages in request. So, this causes problems on architectures where the icache doesn't fill from the dcache or with dcache aliases. The patch fixes this. The ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE symbol was introduced to avoid pointless empty cache-thrashing loops on architectures for which flush_dcache_page() is a no-op. Every architecture was provided with this flush pages on architectires where ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE is equal 1 or do nothing otherwise. See "fix mtd_blkdevs problem with caches on some architectures" discussion on LKML for more information. Signed-off-by: Ilya Loginov <isloginov@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Peter Horton <phorton@bitbox.co.uk> Cc: "Ed L. Cashin" <ecashin@coraid.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-11-26 11:16:19 +03:00
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
#define flush_dcache_page(page) do { } while (0)
#define flush_dcache_mmap_lock(mapping) do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
m68knommu: create optimal separate instruction and data cache for ColdFire Create separate functions to deal with instruction and data cache flushing. This way we can optimize them for the vairous cache types and arrangements used across the ColdFire family. For example the unified caches in the version 3 cores means we don't need to flush the instruction cache. For the version 2 cores that do not do data cacheing (or where we choose instruction cache only) we don't need to do any data flushing. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-10 08:22:19 +03:00
#define flush_icache_range(start, len) __flush_icache_all()
Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
#define flush_icache_page(vma,pg) do { } while (0)
#define flush_icache_user_range(vma,pg,adr,len) do { } while (0)
[PATCH] m68knommu: fix cache actions for ColdFire 5249, 527x and 528x processors Add better support for flushing the cache's on some ColdFire processors. The 5249 cache code is now enabled (it was stubbed out), it really is needed. Add support for the 527x and 528x families - we only use the simple instruction cache on them. Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-13 05:14:08 +04:00
#define flush_cache_vmap(start, end) do { } while (0)
#define flush_cache_vunmap(start, end) do { } while (0)
Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
memcpy(dst, src, len)
#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
memcpy(dst, src, len)
m68knommu: make cache push code ColdFire generic Currently the code to push cache lines is only available to version 4 cores. Version 3 cores may also need to use this if we support copy- back caches on them. Move this code to make it more generic, and useful for all version ColdFire cores. With this in place we can now have a single cache_flush_all() code path that does all the right things on all version cores. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-09 07:27:50 +03:00
void mcf_cache_push(void);
[PATCH] m68knommu: enable cache support code for ColdFIre 5249 Enable the ColdFire 5249 cache support code - it should have been on. Also one more change of "extern inline" to "static inline". Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 07:09:50 +03:00
static inline void __flush_cache_all(void)
Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
{
m68knommu: make cache push code ColdFire generic Currently the code to push cache lines is only available to version 4 cores. Version 3 cores may also need to use this if we support copy- back caches on them. Move this code to make it more generic, and useful for all version ColdFire cores. With this in place we can now have a single cache_flush_all() code path that does all the right things on all version cores. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-09 07:27:50 +03:00
#ifdef CACHE_PUSH
mcf_cache_push();
#endif
m68knommu: clean up ColdFire cache control code The cache control code for the ColdFire CPU's is a big ugly mess of "#ifdef"ery liberally coated with bit constants. Clean it up. The cache controllers in the various ColdFire parts are actually quite similar. Just differing in some bit flags and options supported. Using the header defines now in place it is pretty easy to factor out the small differences and use common setup and flush/invalidate code. I have preserved the cache setups as they where in the old code (except where obviously wrong - like in the case of the 5249). Following from this it should be easy now to extend the possible setups used on the CACHE controllers that support split cacheing or copy-back or write through options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-09 06:35:55 +03:00
#ifdef CACHE_INVALIDATE
m68knommu: fix cache flushing for the 527x ColdFire processors Fix cache flushing for the 527x ColdFire processors Its CACR register format is slightly different. Along with this add support for flushing the 523x cache, which uses the same format as the 527x ColdFire's, and was missing flush support. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-01-13 03:17:30 +03:00
__asm__ __volatile__ (
m68knommu: clean up ColdFire cache control code The cache control code for the ColdFire CPU's is a big ugly mess of "#ifdef"ery liberally coated with bit constants. Clean it up. The cache controllers in the various ColdFire parts are actually quite similar. Just differing in some bit flags and options supported. Using the header defines now in place it is pretty easy to factor out the small differences and use common setup and flush/invalidate code. I have preserved the cache setups as they where in the old code (except where obviously wrong - like in the case of the 5249). Following from this it should be easy now to extend the possible setups used on the CACHE controllers that support split cacheing or copy-back or write through options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-09 06:35:55 +03:00
"movel %0, %%d0\n\t"
m68knommu: fix cache flushing for the 527x ColdFire processors Fix cache flushing for the 527x ColdFire processors Its CACR register format is slightly different. Along with this add support for flushing the 523x cache, which uses the same format as the 527x ColdFire's, and was missing flush support. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-01-13 03:17:30 +03:00
"movec %%d0, %%CACR\n\t"
"nop\n\t"
m68knommu: clean up ColdFire cache control code The cache control code for the ColdFire CPU's is a big ugly mess of "#ifdef"ery liberally coated with bit constants. Clean it up. The cache controllers in the various ColdFire parts are actually quite similar. Just differing in some bit flags and options supported. Using the header defines now in place it is pretty easy to factor out the small differences and use common setup and flush/invalidate code. I have preserved the cache setups as they where in the old code (except where obviously wrong - like in the case of the 5249). Following from this it should be easy now to extend the possible setups used on the CACHE controllers that support split cacheing or copy-back or write through options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-09 06:35:55 +03:00
: : "i" (CACHE_INVALIDATE) : "d0" );
#endif
Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
}
m68knommu: create optimal separate instruction and data cache for ColdFire Create separate functions to deal with instruction and data cache flushing. This way we can optimize them for the vairous cache types and arrangements used across the ColdFire family. For example the unified caches in the version 3 cores means we don't need to flush the instruction cache. For the version 2 cores that do not do data cacheing (or where we choose instruction cache only) we don't need to do any data flushing. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-10 08:22:19 +03:00
/*
* Some ColdFire parts implement separate instruction and data caches,
* on those we should just flush the appropriate cache. If we don't need
* to do any specific flushing then this will be optimized away.
*/
static inline void __flush_icache_all(void)
{
#ifdef CACHE_INVALIDATEI
__asm__ __volatile__ (
"movel %0, %%d0\n\t"
"movec %%d0, %%CACR\n\t"
"nop\n\t"
: : "i" (CACHE_INVALIDATEI) : "d0" );
#endif
}
static inline void __flush_dcache_all(void)
{
#ifdef CACHE_PUSH
mcf_cache_push();
#endif
#ifdef CACHE_INVALIDATED
__asm__ __volatile__ (
"movel %0, %%d0\n\t"
"movec %%d0, %%CACR\n\t"
"nop\n\t"
: : "i" (CACHE_INVALIDATED) : "d0" );
#else
/* Flush the wrtite buffer */
__asm__ __volatile__ ( "nop" );
#endif
}
Linux-2.6.12-rc2 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!
2005-04-17 02:20:36 +04:00
#endif /* _M68KNOMMU_CACHEFLUSH_H */
Reference in New Issue Copy Permalink