From: geert+renesas@glider.be (Geert Uytterhoeven)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/6] ARM: l2c: Add DT support for Shared Override
Date: Mon, 4 May 2015 17:24:27 +0200 [thread overview]
Message-ID: <1430753072-17145-2-git-send-email-geert+renesas@glider.be> (raw)
In-Reply-To: <1430753072-17145-1-git-send-email-geert+renesas@glider.be>
"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.
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,
- If CMA is not available, the "shared attribute override enable" bit
will be set.
See also commit 1a8e41cd672f894b ("ARM: 6395/1: VExpress: Set bit 22 in
the PL310 (cache controller) AuxCtlr register"):
"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."
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3:
- New.
---
Documentation/devicetree/bindings/arm/l2cc.txt | 6 ++++++
arch/arm/mm/cache-l2x0.c | 10 ++++++++++
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index 0dbabe9a6b0abb91..f6f81b263a9cf56d 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -67,6 +67,12 @@ Optional properties:
disable if zero.
- arm,prefetch-offset : Override prefetch offset value. Valid values are
0-7, 15, 23, and 31.
+- arm,shared-override : As of r2p0, the default behavior of the pl310 cache
+ controller with respect to the shareable attribute is to transform "normal
+ memory non-cacheable transactions" into "cacheable no allocate" (for reads)
+ or "write through no write allocate" (for writes).
+ On systems where this may cause DMA buffer corruption, this property must be
+ specified to indicate that such transforms are precluded.
Example:
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index e309c8f35af5af61..535b575ac3d7a52f 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -17,6 +17,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include <linux/cpu.h>
+#include <linux/dma-contiguous.h>
#include <linux/err.h>
#include <linux/init.h>
#include <linux/smp.h>
@@ -1149,6 +1150,15 @@ static void __init l2c310_of_parse(const struct device_node *np,
}
}
+ if (of_property_read_bool(np, "arm,shared-override")) {
+ if (dev_get_cma_area(NULL)) {
+ pr_info("L2C-310 ignoring arm,shared-override when CMA is enabled\n");
+ } else {
+ *aux_val |= L2C_AUX_CTRL_SHARED_OVERRIDE;
+ *aux_mask &= ~L2C_AUX_CTRL_SHARED_OVERRIDE;
+ }
+ }
+
prefetch = l2x0_saved_regs.prefetch_ctrl;
ret = of_property_read_u32(np, "arm,double-linefill", &val);
--
1.9.1
next prev parent reply other threads:[~2015-05-04 15:24 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 ` Geert Uytterhoeven [this message]
2015-05-05 11:21 ` [PATCH v3 1/6] ARM: l2c: Add DT support for " Catalin Marinas
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
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=1430753072-17145-2-git-send-email-geert+renesas@glider.be \
--to=geert+renesas@glider.be \
--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 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).