2011-08-03 17:12:05 +00:00
|
|
|
* ARM L2 Cache Controller
|
|
|
|
|
2015-12-16 07:11:41 +00:00
|
|
|
ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/
|
|
|
|
PL310 and variants) based level 2 cache controller. All these various implementations
|
|
|
|
of the L2 cache controller have compatible programming models (Note 1).
|
2014-09-26 08:01:58 +00:00
|
|
|
Some of the properties that are just prefixed "cache-*" are taken from section
|
|
|
|
3.7.3 of the ePAPR v1.1 specification which can be found at:
|
|
|
|
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
|
|
|
|
|
2011-08-03 17:12:05 +00:00
|
|
|
The ARM L2 cache representation in the device tree should be done as follows:
|
|
|
|
|
|
|
|
Required properties:
|
|
|
|
|
|
|
|
- compatible : should be one of:
|
2013-12-13 15:42:19 +00:00
|
|
|
"arm,pl310-cache"
|
|
|
|
"arm,l220-cache"
|
|
|
|
"arm,l210-cache"
|
|
|
|
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
|
|
|
|
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
|
|
|
|
offset needs to be added to the address before passing down to the L2
|
|
|
|
cache controller
|
|
|
|
"marvell,aurora-system-cache": Marvell Controller designed to be
|
2012-09-26 16:02:50 +00:00
|
|
|
compatible with the ARM one, with system cache mode (meaning
|
|
|
|
maintenance operations on L1 are broadcasted to the L2 and L2
|
|
|
|
performs the same operation).
|
2013-12-13 15:42:19 +00:00
|
|
|
"marvell,aurora-outer-cache": Marvell Controller designed to be
|
|
|
|
compatible with the ARM one with outer cache mode.
|
|
|
|
"marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
|
|
|
|
with arm,pl310-cache controller.
|
2011-08-03 17:12:05 +00:00
|
|
|
- cache-unified : Specifies the cache is a unified cache.
|
|
|
|
- cache-level : Should be set to 2 for a level 2 cache.
|
|
|
|
- reg : Physical base address and size of cache controller's memory mapped
|
|
|
|
registers.
|
|
|
|
|
|
|
|
Optional properties:
|
|
|
|
|
|
|
|
- arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
|
|
|
|
read, write and setup latencies. Minimum valid values are 1. Controllers
|
|
|
|
without setup latency control should use a value of 0.
|
|
|
|
- arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
|
|
|
|
read, write and setup latencies. Controllers without setup latency control
|
|
|
|
should use 0. Controllers without separate read and write Tag RAM latency
|
|
|
|
values should only use the first cell.
|
|
|
|
- arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
|
|
|
|
- arm,filter-ranges : <start length> Starting address and length of window to
|
|
|
|
filter. Addresses in the filter window are directed to the M1 port. Other
|
|
|
|
addresses will go to the M0 port.
|
ARM: 8076/1: mm: add support for HW coherent systems in PL310 cache
When a PL310 cache is used on a system that provides hardware
coherency, the outer cache sync operation is useless, and can be
skipped. Moreover, on some systems, it is harmful as it causes
deadlocks between the Marvell coherency mechanism, the Marvell PCIe
controller and the Cortex-A9.
To avoid this, this commit introduces a new Device Tree property
'arm,io-coherent' for the L2 cache controller node, valid only for the
PL310 cache. It identifies the usage of the PL310 cache in an I/O
coherent configuration. Internally, it makes the driver disable the
outer cache sync operation.
Note that technically speaking, a fully coherent system wouldn't
require any of the other .outer_cache operations. However, in
practice, when booting secondary CPUs, these are not yet coherent, and
therefore a set of cache maintenance operations are necessary at this
point. This explains why we keep the other .outer_cache operations and
only ->sync is disabled.
While in theory any write to a PL310 register could cause the
deadlock, in practice, disabling ->sync is sufficient to workaround
the deadlock, since the other cache maintenance operations are only
used in very specific situations.
Contrary to previous versions of this patch, this new version does not
simply NULL-ify the ->sync member, because the l2c_init_data
structures are now 'const' and therefore cannot be modified, which is
a good thing. Therefore, this patch introduces a separate
l2c_init_data instance, called of_l2c310_coherent_data.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-06-13 09:58:38 +00:00
|
|
|
- arm,io-coherent : indicates that the system is operating in an hardware
|
|
|
|
I/O coherent mode. Valid only when the arm,pl310-cache compatible
|
|
|
|
string is used.
|
2011-08-17 17:03:17 +00:00
|
|
|
- interrupts : 1 combined interrupt.
|
2014-09-26 08:01:58 +00:00
|
|
|
- cache-size : specifies the size in bytes of the cache
|
|
|
|
- cache-sets : specifies the number of associativity sets of the cache
|
|
|
|
- cache-block-size : specifies the size in bytes of a cache block
|
|
|
|
- cache-line-size : specifies the size in bytes of a line in the cache,
|
|
|
|
if this is not specified, the line size is assumed to be equal to the
|
|
|
|
cache block size
|
2012-09-26 16:02:50 +00:00
|
|
|
- cache-id-part: cache id part number to be used if it is not present
|
|
|
|
on hardware
|
|
|
|
- wt-override: If present then L2 is forced to Write through mode
|
2015-01-08 06:52:38 +00:00
|
|
|
- arm,double-linefill : Override double linefill enable setting. Enable if
|
|
|
|
non-zero, disable if zero.
|
|
|
|
- arm,double-linefill-incr : Override double linefill on INCR read. Enable
|
|
|
|
if non-zero, disable if zero.
|
|
|
|
- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
|
|
|
|
if non-zero, disable if zero.
|
|
|
|
- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
|
|
|
|
disable if zero.
|
|
|
|
- arm,prefetch-offset : Override prefetch offset value. Valid values are
|
|
|
|
0-7, 15, 23, and 31.
|
2015-10-27 15:42:06 +00:00
|
|
|
- arm,shared-override : The default behavior of the L220 or PL310 cache
|
|
|
|
controllers 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).
|
ARM: 8395/1: l2c: Add support for the "arm,shared-override" property
"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.
Then, it's up to the OS to decide. The current behavior is to set the
"shared attribute override enable" bit, as there may exist kernel linear
mappings and cacheable aliases for the DMA buffers, even if CMA is
enabled.
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>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-06-26 07:09:29 +00:00
|
|
|
On systems where this may cause DMA buffer corruption, this property must be
|
|
|
|
specified to indicate that such transforms are precluded.
|
2015-10-27 15:42:06 +00:00
|
|
|
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
|
|
|
|
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
|
2015-12-15 14:56:47 +00:00
|
|
|
- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
|
|
|
|
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
|
|
|
|
will randomly hang unless outer sync operations are disabled.
|
2015-06-10 19:23:24 +00:00
|
|
|
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
|
|
|
|
(forcibly enable), property absent (retain settings set by firmware)
|
|
|
|
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
|
|
|
|
<1> (forcibly enable), property absent (retain settings set by
|
|
|
|
firmware)
|
2011-08-03 17:12:05 +00:00
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
L2: cache-controller {
|
|
|
|
compatible = "arm,pl310-cache";
|
|
|
|
reg = <0xfff12000 0x1000>;
|
|
|
|
arm,data-latency = <1 1 1>;
|
|
|
|
arm,tag-latency = <2 2 2>;
|
2012-10-24 00:53:06 +00:00
|
|
|
arm,filter-ranges = <0x80000000 0x8000000>;
|
2011-08-03 17:12:05 +00:00
|
|
|
cache-unified;
|
|
|
|
cache-level = <2>;
|
2011-08-17 17:03:17 +00:00
|
|
|
interrupts = <45>;
|
2011-08-03 17:12:05 +00:00
|
|
|
};
|
2015-12-16 07:11:41 +00:00
|
|
|
|
|
|
|
Note 1: The description in this document doesn't apply to integrated L2
|
|
|
|
cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
|
|
|
|
integrated L2 controllers are assumed to be all preconfigured by
|
|
|
|
early secure boot code. Thus no need to deal with their configuration
|
|
|
|
in the kernel at all.
|