From: shiraz.hashim@st.com (Shiraz Hashim)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Set bit 22 in the PL310 (cache controller) AuxCtlr register
Date: Mon, 12 Nov 2012 12:15:47 +0530 [thread overview]
Message-ID: <20121112064547.GN32313@localhost.localdomain> (raw)
In-Reply-To: <20121109095400.GC2357@mudshark.cambridge.arm.com>
On Fri, Nov 09, 2012 at 09:54:01AM +0000, Will Deacon wrote:
> On Fri, Nov 09, 2012 at 04:01:52AM +0000, Shiraz Hashim wrote:
> > From: Catalin Marinas <catalin.marinas@arm.com>
> >
> > Clearing bit 22 in the PL310 Auxiliary Control register (shared
> > attribute override enable) has the side effect of transforming Normal
> > Shared Non-cacheable reads into Cacheable no-allocate reads.
> >
> > Coherent DMA buffers in Linux always have a Cacheable alias via the
> > kernel linear mapping and the processor can speculatively load cache
> > lines into the PL310 controller. With bit 22 cleared, Non-cacheable
> > reads would unexpectedly hit such cache lines leading to buffer
> > corruption.
>
> Is this still the case with recent kernels? I thought the dma-mapping/cma
> work avoided the cacheable alias, but perhaps I'm mistaken.
I haven't used CMA but DMA mappings are still normal memory
non-cacheable.
--
regards
Shiraz
WARNING: multiple messages have this Message-ID (diff)
From: Shiraz Hashim <shiraz.hashim@st.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>,
"spear-devel@list.st.com" <spear-devel@list.st.com>,
"alain.pasteur@st.com" <alain.pasteur@st.com>,
"Joerg.Wienand@sma.de" <Joerg.Wienand@sma.de>, <amit.goel@st.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Set bit 22 in the PL310 (cache controller) AuxCtlr register
Date: Mon, 12 Nov 2012 12:15:47 +0530 [thread overview]
Message-ID: <20121112064547.GN32313@localhost.localdomain> (raw)
In-Reply-To: <20121109095400.GC2357@mudshark.cambridge.arm.com>
On Fri, Nov 09, 2012 at 09:54:01AM +0000, Will Deacon wrote:
> On Fri, Nov 09, 2012 at 04:01:52AM +0000, Shiraz Hashim wrote:
> > From: Catalin Marinas <catalin.marinas@arm.com>
> >
> > Clearing bit 22 in the PL310 Auxiliary Control register (shared
> > attribute override enable) has the side effect of transforming Normal
> > Shared Non-cacheable reads into Cacheable no-allocate reads.
> >
> > Coherent DMA buffers in Linux always have a Cacheable alias via the
> > kernel linear mapping and the processor can speculatively load cache
> > lines into the PL310 controller. With bit 22 cleared, Non-cacheable
> > reads would unexpectedly hit such cache lines leading to buffer
> > corruption.
>
> Is this still the case with recent kernels? I thought the dma-mapping/cma
> work avoided the cacheable alias, but perhaps I'm mistaken.
I haven't used CMA but DMA mappings are still normal memory
non-cacheable.
--
regards
Shiraz
next parent reply other threads:[~2012-11-12 6:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1352433712-16364-1-git-send-email-shiraz.hashim@st.com>
[not found] ` <20121109095400.GC2357@mudshark.cambridge.arm.com>
2012-11-12 6:45 ` Shiraz Hashim [this message]
2012-11-12 6:45 ` [PATCH] Set bit 22 in the PL310 (cache controller) AuxCtlr register Shiraz Hashim
2012-11-12 10:56 ` Will Deacon
2012-11-12 10:56 ` Will Deacon
2012-11-16 10:46 ` Shiraz Hashim
2012-11-16 10:46 ` Shiraz Hashim
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=20121112064547.GN32313@localhost.localdomain \
--to=shiraz.hashim@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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: link
Be 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.