On Tue, Nov 17, 2009 at 12:00:18PM +0100, Marc Zyngier wrote: > Then what about introducing a CORTEX_A8 symbol, selected by ARCH_OMAP3, > ARCH_S5PC1XX and others to come, and that would select the right cache > line value? We really want to avoid those ever growing dependency lines > that lead to conflicts when applying patches from multiple sources. > > Unless we can have a Cortex-A8 implementation with a cache line that is > not 64 bytes? CPUs of the same family can have different cache line sizes. The only way to be sure is if you read the cache type registers and work it out. However, L1_CACHE_SHIFT must be a compile time constant - it can't be run-time calculated. So, we chose to set L1_CACHE_SHIFT to be the largest size found for the SoC concerned. So, setting it to 64 for CPU_V7 makes no sense, since such CPUs can have larger or smaller cache line sizes - and that's about the same as trying to select the cache line size according to a CORTEX_A8 symbol... The original patch seems to be the only sensible solution to this. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |