From: Catalin Marinas <catalin.marinas@arm.com>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>, Simon Horman <horms@verge.net.au>,
Magnus Damm <magnus.damm@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Pawel Moll <pawel.moll@arm.com>,
devicetree@vger.kernel.org, linux-sh@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Tushar Behera <tushar.behera@linaro.org>
Subject: Re: [PATCH v3 1/6] ARM: l2c: Add DT support for Shared Override
Date: Tue, 5 May 2015 12:21:46 +0100 [thread overview]
Message-ID: <20150505112145.GG22384@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <1430753072-17145-2-git-send-email-geert+renesas@glider.be>
On Mon, May 04, 2015 at 05:24:27PM +0200, Geert Uytterhoeven wrote:
> "CoreLink Level 2 Cache Controller L2C-310", p. 2-15, section 2.3.2
> Shareable attribute" states:
>
> "The default behavior of the cache controller with respect to the
> shareable attribute is to transform Normal Memory Non-cacheable
> transactions into:
> - cacheable no allocate for reads
> - write through no write allocate for writes."
>
> Depending on the system architecture, this may cause memory corruption
> in the presence of bus mastering devices (e.g. OHCI). To avoid such
> corruption, the default behavior can be disabled by setting the Shared
> Override bit in the Auxiliary Control register.
>
> Currently the Shared Override bit can be set only using C code:
> - by calling l2x0_init() directly, which is deprecated,
> - by setting/clearing the bit in the machine_desc.l2c_aux_val/mask
> fields, but using values differing from 0/~0 is also deprecated.
Or you can set it in firmware/boot-loader before Linux starts.
> Hence add support for an "arm,shared-override" device tree property for
> the l2c device node. By specifying this property, affected systems can
> indicate that non-cacheable transactions must not be transformed.
>
> If specified, the actual behavior of the kernel depends on whether CMA
> is available or not:
> - If CMA is available, nothing needs to be done, as there won't be a
> kernel linear mappings and cacheable aliases for the DMA buffers,
I don't think this is true. See this thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/329492.html
> - If CMA is not available, the "shared attribute override enable" bit
> will be set.
IMO, this should always be done, independent of any DT or kernel
configuration. I stated it several times already that I don't see why we
would ever need such bit cleared:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330573.html
Personally I don't think this configuration belongs to the DT,
especially as it may depend on how the OS is configured. But since
Russell has refused to take patches setting this bit by default (I have
yet to see a valid argument), it's still better than nothing.
--
Catalin
next prev parent reply other threads:[~2015-05-05 11:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 15:24 [PATCH v3 0/6] ARM: l2c / shmobile: r8a7740 : Shared Override Geert Uytterhoeven
2015-05-04 15:24 ` [PATCH v3 1/6] ARM: l2c: Add DT support for " Geert Uytterhoeven
2015-05-05 11:21 ` Catalin Marinas [this message]
2015-05-05 11:42 ` Geert Uytterhoeven
2015-05-05 14:22 ` Catalin Marinas
2015-05-05 14:55 ` Geert Uytterhoeven
2015-05-05 15:51 ` Catalin Marinas
2015-05-05 16:34 ` Rob Herring
2015-05-04 15:24 ` [PATCH v3 2/6] ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node Geert Uytterhoeven
[not found] ` <1430753072-17145-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
2015-05-04 15:24 ` [PATCH v3 3/6] ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization Geert Uytterhoeven
2015-05-04 15:24 ` [PATCH v3 4/6] ARM: shmobile: armadillo legacy: " Geert Uytterhoeven
2015-05-04 15:24 ` [PATCH v3 5/6] ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers Geert Uytterhoeven
2015-05-04 15:24 ` [PATCH v3 6/6] ARM: shmobile: r8a7740 dtsi: Add L1 cache information to CPU node Geert Uytterhoeven
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=20150505112145.GG22384@e104818-lin.cambridge.arm.com \
--to=catalin.marinas@arm.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=magnus.damm@gmail.com \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=tushar.behera@linaro.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 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).