diff mbox

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

Message ID efa5fda5ae625a43fac14bf173cbd96ad7b44e7a.1396605300.git.nsekhar@ti.com
State New
Headers show

Commit Message

Sekhar Nori April 4, 2014, 10:10 a.m. UTC
Add support for L2 cache controller (PL310) on
AM437x SoC.

Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
 arch/arm/mach-omap2/Kconfig        |    1 +
 arch/arm/mach-omap2/common.h       |    1 +
 arch/arm/mach-omap2/io.c           |    1 +
 arch/arm/mach-omap2/omap4-common.c |    8 ++++++++
 4 files changed, 11 insertions(+)

Comments

Russell King - ARM Linux April 4, 2014, 10:18 a.m. UTC | #1
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.
Sekhar Nori April 8, 2014, 2:53 p.m. UTC | #2
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.

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.

3) OMAP4 sets cache replacement policy to RR which is not a big deal
since thats the default anyway. We can probably drop this setting even
from OMAP4.

Thanks,
Sekhar

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar April 8, 2014, 3:17 p.m. UTC | #3
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.

> 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.
 
> 3) OMAP4 sets cache replacement policy to RR which is not a big deal
> since thats the default anyway. We can probably drop this setting even
> from OMAP4.
> 
Don't change anything on OMAP4 since these settings have come up from
multiple alignments.

In my view, Aegis can use exact same setting as OMAP4. Things like
shared bit etc would not make much difference because of UP config,
keeping that doesn't hurt either.

Why don't you just re-use that as is ? Sorry if I have missed any
other discussion on the thread.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sekhar Nori April 9, 2014, 9:44 a.m. UTC | #4
On Tuesday 08 April 2014 08:47 PM, 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.

Can you please explain a little bit more since I am obviously lacking
the background on OMAP4?

Commit b0f20ff9 ("omap4: l2x0: Set share override bit") talks about
possibility of data corruption due to speculative prefetch and coherent
DMA buffers having a cachable alias. But based on recent mailing list
discussions, with introduction of CMA, we should not have such a
cachable alias since the mapping is modified in place. If
arm_memblock_steal() or memblock_remove() is used, thats not a problem
as well since that memory is not mapped in kernel page tables.

As I indicated earlier, I am too not in favor of changing anything on
OMAP4 but it will be instructive to know exactly which scenarios shared
bit becomes mandatory on OMAP4.

>> 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.

Okay. AFAIK, There has not been such a recommendation from hardware team
of AM437x AFAIK. But, the AM437x ROM does leave these two bits set after
booting so even though Linux does not touch these, these are already set.

Given this, I see no reason for not setting the same bits again from
Linux just to get close to OMAP4 code.

>  
>> 3) OMAP4 sets cache replacement policy to RR which is not a big deal
>> since thats the default anyway. We can probably drop this setting even
>> from OMAP4.
>>
> Don't change anything on OMAP4 since these settings have come up from
> multiple alignments.

I agree. Thats what the $subject series is doing too.

> In my view, Aegis can use exact same setting as OMAP4. Things like
> shared bit etc would not make much difference because of UP config,
> keeping that doesn't hurt either.
> 
> Why don't you just re-use that as is ? Sorry if I have missed any
> other discussion on the thread.

We could reuse as is. I don't see any functional issue. This is what I
will probably do for the next version of the series. The only setting
thats actually being done differently is the Shared attribute override
enable bit.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux April 9, 2014, 4:23 p.m. UTC | #5
On Tue, Apr 08, 2014 at 08:23:39PM +0530, 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.
> 
> 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.

That is required because as part of the enable sequence, we write to the
lockdown registers to clear out anything that may be there before we
enable the L2 cache.  If we didn't set the NS lockdown bit, then we
would need the secure monitor to do it for us.

The NS interrupt access bit is also a good idea to be set, since this
allows us to eventually support EDAC with PL310.  As we don't support
EDAC at the moment, or touch the interrupt registers, we can probably
ignore this difference and just preserve whatever value is there for
the time being.

Both of these bits should be managed within the L2C code rather than by
platforms.

> 3) OMAP4 sets cache replacement policy to RR which is not a big deal
> since thats the default anyway. We can probably drop this setting even
> from OMAP4.

Yes, since that would just be a case of preserving that bit.
Russell King - ARM Linux April 9, 2014, 4:33 p.m. UTC | #6
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.
Santosh Shilimkar April 9, 2014, 4:52 p.m. UTC | #7
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.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sekhar Nori April 10, 2014, 11:56 a.m. UTC | #8
On Wednesday 09 April 2014 09:53 PM, Russell King - ARM Linux wrote:
> On Tue, Apr 08, 2014 at 08:23:39PM +0530, 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.
>>
>> 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.
> 
> That is required because as part of the enable sequence, we write to the
> lockdown registers to clear out anything that may be there before we
> enable the L2 cache.  If we didn't set the NS lockdown bit, then we
> would need the secure monitor to do it for us.

And I realized yesterday that the only reason L2C is working on AM437x
is because AM437x ROM is setting these bits up for us.

> 
> The NS interrupt access bit is also a good idea to be set, since this
> allows us to eventually support EDAC with PL310.  As we don't support
> EDAC at the moment, or touch the interrupt registers, we can probably
> ignore this difference and just preserve whatever value is there for
> the time being.
> 
> Both of these bits should be managed within the L2C code rather than by
> platforms.

The current L2C code is not managing the NS_LOCKDOWN bit. I can take a
shot at adding this support unless you are already looking at it.

> 
>> 3) OMAP4 sets cache replacement policy to RR which is not a big deal
>> since thats the default anyway. We can probably drop this setting even
>> from OMAP4.
> 
> Yes, since that would just be a case of preserving that bit.

Okay will drop this explicit setting.

Thanks,
Sekhar


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sekhar Nori April 10, 2014, 12:08 p.m. UTC | #9
On Wednesday 09 April 2014 10:22 PM, Santosh Shilimkar wrote:
> 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.

Since we cannot guarantee that CONFIG_DMA_CMA will always be enabled in
kernel config, shall we take the safer route and keep the Shared
attribute override bit enabled in L2C configuration?

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sekhar Nori April 10, 2014, 12:16 p.m. UTC | #10
On Thursday 10 April 2014 05:33 PM, Russell King - ARM Linux wrote:
> On Thu, Apr 10, 2014 at 05:26:15PM +0530, Sekhar Nori wrote:
>> On Wednesday 09 April 2014 09:53 PM, Russell King - ARM Linux wrote:
>>> That is required because as part of the enable sequence, we write to the
>>> lockdown registers to clear out anything that may be there before we
>>> enable the L2 cache.  If we didn't set the NS lockdown bit, then we
>>> would need the secure monitor to do it for us.
>>
>> And I realized yesterday that the only reason L2C is working on AM437x
>> is because AM437x ROM is setting these bits up for us.
>>
>>> Both of these bits should be managed within the L2C code rather than by
>>> platforms.
>>
>> The current L2C code is not managing the NS_LOCKDOWN bit. I can take a
>> shot at adding this support unless you are already looking at it.
> 
> True, and I'm aware that it's missing.  So... how about this on top
> of my series so far.  We can deal with L310_AUX_CTRL_NS_INT_CTRL when
> the need to access those registers arises (if/when the edac driver
> is submitted.)
> 
> diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
> index c0f9a81a2d32..4a494cde8367 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -213,8 +213,6 @@ static int __init omap_l2_cache_init(void)
>  
>  	/* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
>  	aux_ctrl = L310_AUX_CTRL_CACHE_REPLACE_RR |
> -		   L310_AUX_CTRL_NS_LOCKDOWN |
> -		   L310_AUX_CTRL_NS_INT_CTRL |
>  		   L2C_AUX_CTRL_SHARED_OVERRIDE |
>  		   L310_AUX_CTRL_DATA_PREFETCH |
>  		   L310_AUX_CTRL_INSTR_PREFETCH;
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 98796b789eb9..837f384c1d51 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -776,6 +776,13 @@ static void __init l2c310_enable(void __iomem *base, u32 aux, unsigned num_lock)
>  			power_ctrl & L310_STNDBY_MODE_EN ? "en" : "dis");
>  	}
>  
> +	/*
> +	 * Always enable non-secure access to the lockdown registers -
> +	 * we write to them as part of the L2C enable sequence so they
> +	 * need to be accessible.
> +	 */
> +	aux |= L310_AUX_CTRL_NS_LOCKDOWN;
> +

This will work. NS_LOCKDOWN is required for L2C-220 as well and so I was
thinking about adding a new l2c220_enable() which will set the
NS_LOCKDOWN and then call l2c_enable()

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1124155..1fd34d2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -65,6 +65,7 @@  config SOC_AM43XX
 	select ARCH_HAS_OPP
 	select ARM_GIC
 	select MACH_OMAP_GENERIC
+	select MIGHT_HAVE_CACHE_L2X0
 
 config SOC_DRA7XX
 	bool "TI DRA7XX"
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index c64d5f5..fc59b49 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -93,6 +93,7 @@  extern void omap3_gptimer_timer_init(void);
 extern void omap4_local_timer_init(void);
 int omap4_l2_cache_init(void);
 extern void omap5_realtime_timer_init(void);
+int am43xx_l2_cache_init(void);
 
 void omap2420_init_early(void);
 void omap2430_init_early(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 81bc89c..131c207 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -609,6 +609,7 @@  void __init am43xx_init_early(void)
 	am43xx_clockdomains_init();
 	am43xx_hwmod_init();
 	omap_hwmod_init_postsetup();
+	am43xx_l2_cache_init();
 	omap_clk_soc_init = am43xx_dt_clk_init;
 }
 
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;
+
+	return omap_l2_cache_init(aux_ctrl, 0xcfffffff);
+}
 #endif
 
 void __iomem *omap4_get_sar_ram_base(void)