[PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support

[Russell King - ARM Linux]

On Tue, Apr 08, 2014 at 11:17:17AM -0400, Santosh Shilimkar wrote:
> On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
> > On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
> >> On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
> >>> diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
> >>> index f8b8dac..6b2a056 100644
> >>> --- a/arch/arm/mach-omap2/omap4-common.c
> >>> +++ b/arch/arm/mach-omap2/omap4-common.c
> >>> @@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
> >>>  
> >>>  	return omap_l2_cache_init(aux_ctrl, 0xc19fffff);
> >>>  }
> >>> +
> >>> +int __init am43xx_l2_cache_init(void)
> >>> +{
> >>> +	u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
> >>> +		       L310_AUX_CTRL_INSTR_PREFETCH;
> >>
> >> It would be good to documenting the difference between this and OMAP4,
> >> and why you have chosen different values.
> > 
> > There are two main differences:
> > 
> > 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
> > not needed even in OMAP4 with latest kernel, but I am not sure if I can
> > do this safely without breaking any usecase currently working with OMAP4.
> > 
> Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
> which needs that.

Errr.  This bit affects the L2 cache behaviour for Normal memory, outer
non-cacheable accesses - in other words, those performed to memory mapped
via dma_alloc_coherent() or dma_alloc_writecombine().  It does not affect
other types of mappings (other access types ignore the sharable attribute).

When this bit is clear, accesses to such memory are:

- read: cacheable, no allocate
- write: write through, no write allocate

what this means is that if there are no cache lines in the L2 cache
corresponding with the physical address, then none will be allocated.
However, if there are cache lines present, then they will be hit,
read or updated as appropriate.

This may matter before CMA where we had the memory returned by
dma_alloc_coherent() and friends mapped as normal, cacheable mappings
which could be speculatively prefetched, and therefore cache lines
dragged into the L2 cache for these physical addresses.

However, now that we're using CMA, this does not apply as we no longer
have this aliasing mapping.

So, with CMA enabled, it should be safe not to set this bit.

However, the shared bit in the page tables must be set for SMP systems.
Are you sure you're not confusing the shared bit in the page tables
with the shared override bit in the L2 cache controller?

> > 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
> > searched through the commit history of L2 cache support on OMAP4 but
> > there is no mention of why this was needed on OMAP4. I am checking
> > internally on the history behind this.
> >
> These have also come from the aligned settings with hardware folks.

Again, this doesn't have much to do with hardware, it's secure/non-secure
access rights configuration to the L2 cache controller.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.