OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?

[catalin.marinas@arm.com (Catalin Marinas)]

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