Becky Bruce wrote:
<snip>
This is where Detlev's comment about using the chance to define a cache API comes into play.
Yes, we probably should create a set of functions like
enable_data_cache(address, size);and disable_data_cache(address, size);
which would turn on resp. off the caching attributes on the given memory range.
<snip>
Using a completely different address range instead is a different thing, and not what I have in mind. I really dislike the idea of supporting "alternate addresses" in this context - even if this is what would be easiest to implement on some architectures.
I agree, but, then, I'm coming from an architecture where doing this is bad joo-joo. Again, it looks like AVR may actually need this - hopefully someone who knows more about AVR will speak up here.
Although I wouldn't consider myself an AVR32 "expert", I am following this thread closely. It seems to me that the above 2 functions could be used to support Detlev's idea as well as Haavard's map_physmem() idea.
The functions could also return (architecture dependant) a "remapped" address to be used, then we could support:-
(1) AVR32-type cache which is based on different address ranges
Here the xxx_data_cache() functions would flush the cache, and return a new address that points to the relevant cached / uncached section of memory.
(2) Platforms with "single address" ranges but finer cache control
These would flush the cache, adjust the caching for the memory range as required, and then just return the *same* address (since no address re-mapping is required).
The functions using xxx_data_cache() would then code up as follows:-
void foo(address, size) { uncached_address = disable_data_cache(address, size); /* * ... do some code using only uncached_address ... */ cached_address = enable_data_cache(address, size); }
Regards Mark