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

Santosh Shilimkar santosh.shilimkar at ti.com
Wed Apr 9 09:52:36 PDT 2014

On Wednesday 09 April 2014 12:33 PM, Russell King - ARM Linux wrote:
> 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.
Agree. That should be safe now.

> 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?
No i didn't confuse with page table bits. But the SMP remark wasn't
relevant which might have indicated that.
>>> 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.
The settings were aligned by hardware team after consulting security
team and those couple of bit settings came from them. The folks
are no longer working for TI so I can't go back and check the reasons.
We just just leave them as is.


More information about the linux-arm-kernel mailing list