From: Catalin Marinas <catalin.marinas@arm.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Nick Piggin <npiggin@suse.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Mackerras <paulus@samba.org>,
linux-arch@vger.kernel.org, Russell King <rmk@arm.linux.org.uk>,
Francois Romieu <romieu@fr.zoreil.com>
Subject: Re: SMP barriers semantics
Date: Mon, 26 Apr 2010 10:21:21 +0100 [thread overview]
Message-ID: <1272273681.11974.6.camel@e102109-lin.cambridge.arm.com> (raw)
In-Reply-To: <20100424014536.GD15349@shareable.org>
On Sat, 2010-04-24 at 02:45 +0100, Jamie Lokier wrote:
> Catalin Marinas wrote:
> > On recent ARM cores, it's only the Strongly Ordered memory that can have
> > the write buffering disabled. But using such mapping for
> > dma_alloc_coherent() introduces other problems like cache attribute
> > aliases for a physical location (since the kernel maps the RAM as Normal
> > memory already). Such aliases are not allowed hence we moved to Normal
> > Non-cacheable for dma_alloc_coherent().
>
> I'm surprised aliases between Normal-Cached and Normal-Uncached are ok,
> while aliases between Normal-Cached and SO-Uncached are not ok.
In theory, all of the aliases are banned but the Normal cacheable vs
non-cacheable have been allowed in practice and current ARM
implementations can cope with it (such "palliative" measures have been
introduced in 2006). Other aliases aren't guaranteed to work correctly.
Normal Non-cacheable memory uses the write buffer (at both the CPU and
L2 cache level) while the Strongly Ordered doesn't. Normal memory
accesses on the same CPU check the write buffer as well since a CPU is
coherent with itself (on the D side).
--
Catalin
next prev parent reply other threads:[~2010-04-26 9:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 10:52 SMP barriers semantics Catalin Marinas
2010-03-03 0:55 ` Paul Mackerras
2010-03-03 12:03 ` Catalin Marinas
2010-03-12 12:31 ` Ralf Baechle
2010-03-12 20:38 ` Jamie Lokier
2010-03-17 2:25 ` Benjamin Herrenschmidt
2010-03-17 10:31 ` Catalin Marinas
2010-03-17 13:42 ` Jamie Lokier
2010-03-22 12:02 ` Nick Piggin
2010-03-23 3:42 ` Nick Piggin
2010-03-23 10:24 ` Catalin Marinas
2010-04-06 14:20 ` Nick Piggin
2010-04-06 15:43 ` Jamie Lokier
2010-04-06 16:04 ` Nick Piggin
2010-04-23 16:23 ` Catalin Marinas
2010-04-23 16:56 ` Jamie Lokier
2010-04-23 17:25 ` Catalin Marinas
2010-04-24 1:45 ` Jamie Lokier
2010-04-26 9:21 ` Catalin Marinas [this message]
2010-03-04 2:23 ` David Dillow
2010-03-04 9:33 ` Russell King
2010-03-04 9:48 ` Catalin Marinas
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=1272273681.11974.6.camel@e102109-lin.cambridge.arm.com \
--to=catalin.marinas@arm.com \
--cc=benh@kernel.crashing.org \
--cc=jamie@shareable.org \
--cc=linux-arch@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
--cc=romieu@fr.zoreil.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).