[PATCH v2 1/5] [ppc] Process dynamic relocations for kernel

[Josh Poimboeuf]

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
> like:
> 
> for e.g, on 440x, (in head_44x.S :)
> 
> #ifdef CONFIG_RELOCATABLE
> 	...
> 	bl relocate
> 
> 	#Flush the d-cache and invalidate the i-cache here
> #endif
> 
> 
> 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
clean_dcache().

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
needed.


Josh