[PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
jpoimboe at linux.vnet.ibm.com
Wed Nov 9 03:19:05 EST 2011
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
> What I was suggesting is, instead of flushing the cache in relocate(), lets do it
> for e.g, on 440x, (in head_44x.S :)
> #ifdef CONFIG_RELOCATABLE
> bl relocate
> #Flush the d-cache and invalidate the i-cache here
> This would let the different platforms do the the cache invalidation in their
> own way.
> Btw, I didn't find an instruction to flush the entire d-cache in PPC440 manual.
> We have instructions to flush only a block corresponding to an address.
> However, we have 'iccci' which would invalidate the entire i-cache which, which
> I think is better than 80,000 i-cache invalidates.
In misc_32.S there are already some platform-independent cache
management functions. If we use those, then relocate() could simply
call them. Then the different platforms calling relocate() wouldn't
have to worry about flushing/invalidating caches.
For example, there's a clean_dcache_range() function. Given any range
twice the size of the d-cache, it should flush the entire d-cache. But
the only drawback is that it would require the caller to know the size
of the d-cache.
Instead, I think it would be preferable to create a new clean_dcache()
(or clean_dcache_all()?) function in misc_32.S, which could call
clean_dcache_range() with the appropriate args for flushing the entire
d-cache. relocate() could then call the platform-independent
For i-cache invalidation there's already the (incorrectly named?)
flush_instruction_cache(). It uses the appropriate platform-specific
methods (e.g. iccci for 44x) to invalidate the entire i-cache.
Suzuki, if you agree with this direction, I could work up a new patch if
More information about the Linuxppc-dev