From: Russell King - ARM Linux <linux@arm.linux.org.uk> To: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Sekhar Nori <nsekhar@ti.com>, Tony Lindgren <tony@atomide.com>, Linux OMAP Mailing List <linux-omap@vger.kernel.org>, Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support Date: Wed, 9 Apr 2014 17:33:30 +0100 [thread overview] Message-ID: <20140409163330.GI27282@n2100.arm.linux.org.uk> (raw) In-Reply-To: <534412FD.5030308@ti.com> 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.
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support Date: Wed, 9 Apr 2014 17:33:30 +0100 [thread overview] Message-ID: <20140409163330.GI27282@n2100.arm.linux.org.uk> (raw) In-Reply-To: <534412FD.5030308@ti.com> 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.
next prev parent reply other threads:[~2014-04-09 16:34 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-04-04 10:10 [PATCH v2 0/3] ARM: OMAP2+: AM437x: L2 cache support Sekhar Nori 2014-04-04 10:10 ` Sekhar Nori 2014-04-04 10:10 ` [PATCH v2 1/3] ARM: OMAP2+: L2 cache: allow different aux ctrl settings Sekhar Nori 2014-04-04 10:10 ` Sekhar Nori 2014-04-04 10:10 ` [PATCH v2 2/3] ARM: OMAP2+: L2 cache: get rid of init call Sekhar Nori 2014-04-04 10:10 ` Sekhar Nori 2014-04-04 10:10 ` [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support Sekhar Nori 2014-04-04 10:10 ` Sekhar Nori 2014-04-04 10:18 ` Russell King - ARM Linux 2014-04-04 10:18 ` Russell King - ARM Linux 2014-04-08 14:53 ` Sekhar Nori 2014-04-08 14:53 ` Sekhar Nori 2014-04-08 15:17 ` Santosh Shilimkar 2014-04-08 15:17 ` Santosh Shilimkar 2014-04-09 9:44 ` Sekhar Nori 2014-04-09 9:44 ` Sekhar Nori 2014-04-09 16:33 ` Russell King - ARM Linux [this message] 2014-04-09 16:33 ` Russell King - ARM Linux 2014-04-09 16:52 ` Santosh Shilimkar 2014-04-09 16:52 ` Santosh Shilimkar 2014-04-10 12:08 ` Sekhar Nori 2014-04-10 12:08 ` Sekhar Nori 2014-04-09 16:23 ` Russell King - ARM Linux 2014-04-09 16:23 ` Russell King - ARM Linux 2014-04-10 11:56 ` Sekhar Nori 2014-04-10 11:56 ` Sekhar Nori 2014-04-10 12:03 ` Russell King - ARM Linux 2014-04-10 12:03 ` Russell King - ARM Linux 2014-04-10 12:16 ` Sekhar Nori 2014-04-10 12:16 ` Sekhar Nori 2014-04-10 13:27 ` Sekhar Nori 2014-04-10 13:27 ` Sekhar Nori 2014-04-10 13:40 ` Russell King - ARM Linux 2014-04-10 13:40 ` Russell King - ARM Linux 2014-04-11 5:33 ` Sekhar Nori 2014-04-11 5:33 ` Sekhar Nori 2014-04-11 11:25 ` Russell King - ARM Linux 2014-04-11 11:25 ` Russell King - ARM Linux 2014-04-11 12:01 ` Sekhar Nori 2014-04-11 12:01 ` Sekhar Nori 2014-04-22 5:48 ` Sekhar Nori 2014-04-22 5:48 ` Sekhar Nori
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140409163330.GI27282@n2100.arm.linux.org.uk \ --to=linux@arm.linux.org.uk \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=nsekhar@ti.com \ --cc=santosh.shilimkar@ti.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.