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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
