| Message ID | efa5fda5ae625a43fac14bf173cbd96ad7b44e7a.1396605300.git.nsekhar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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
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
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.
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.
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
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
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
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)
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(+)