On Tue, Jan 17, 2012 at 12:27:25PM +0000, Aneesh V wrote: > Hi Catalin, > > On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote: > > On Tue, Jan 17, 2012 at 08:54:44AM +0000, Joe Woodward wrote: > >> So, is the upshot of this that the kernel isn't going to be in a > >> position to enable the L2/outer cache on OMAP3 (due to the need for > >> hacky/unmaintainable code)? > >> > >> Hence the bootloader/uBoot had better leave it enabled... > > > > It could but the Linux decompressor needs to be aware and either flush > > the L2 (more difficult as it doesn't have all the device information) or > > Cortex-A8 is aware of L2$ and can flush it, isn't it? As I said to Santosh, I only had the outer cache in mind (e.g. PL310). There is no extra configuration needed in the kernel decompressor in this case. > > set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100). > > If the above is right, this is not needed right? Correct, since L2 is inner cache. > > The latter may still not work if there are stale L2 cache lines left by > > U-Boot (and that's always possible unless U-Boot also uses outer > > non-cacheable memory attributes). > > U-Boot flushes the caches before disabling it. On top of it, it does an > invalidate after the disabling the caches to cover some corner case. > So, it's guaranteed that there won't be any stale entries in L2 after > U-Boot. > > So, we could as well leave L2$ enabled (and invalidated) and caches > disabled globally after U-Boot. Yes. > But I thought enabling L2$ again in kernel is the cleaner solution. Why? It gets enabled via SCTLR.M together with L1. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
