From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 3/3] ARM: mvebu: implement L2/PCIe deadlock workaround
Date: Fri, 16 May 2014 09:07:27 +0200 [thread overview]
Message-ID: <20140516090727.5264dc75@free-electrons.com> (raw)
In-Reply-To: <20140516060851.GF27822@titan.lakedaemon.net>
Dear Jason Cooper,
On Fri, 16 May 2014 02:08:51 -0400, Jason Cooper wrote:
> On Thu, May 15, 2014 at 04:59:34PM +0200, Thomas Petazzoni wrote:
> > The Marvell Armada 375 and Armada 38x SOCs, which use the Cortex-A9
> > CPU core, the PL310 cache and the Marvell PCIe hardware block are
> > affected a L2/PCIe deadlock caused by a system erratum when hardware
> > I/O coherency is used.
> >
> > This deadlock can be avoided by mapping the PCIe memory areas as
> > strongly-ordered (note: MT_UNCACHED is strongly-ordered), and by
> > removing the outer cache sync done in software. This is implemented in
> > this patch by:
> >
> > * Registering a custom arch_ioremap_caller function that allows to
> > make sure PCI memory regions are mapped MT_UNCACHED.
> >
> > * Adding at runtime the 'arm,io-coherent' property to the PL310 cache
> > controller. This cannot be done permanently in the DT, because the
> > hardware I/O coherency can only be enabled when CONFIG_SMP is
> > enabled, in the current kernel situation.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > ---
> > arch/arm/mach-mvebu/coherency.c | 39 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 39 insertions(+)
>
> Applied to mvebu/soc.
Hum, well, I believe it's OK, but notice that I will very likely have
to do a followup patch, because the solution of making all PCI I/O
mappings use the MT_UNCACHED memory type, suggested by Arnd, has not
been accepted by Will Deacon. So very likely I will have to change
again the mach-mvebu/coherency.c code to call a function that makes PCI
I/O mappings MT_UNCACHED specifically for the mach-mvebu platform. But
that can indeed be a followup patch.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-05-16 7:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 14:59 [PATCHv4 0/3] ARM: implement workaround for Cortex-A9/PL310/PCIe deadlock Thomas Petazzoni
2014-05-15 14:59 ` [PATCHv4 1/3] ARM: mm: use MT_UNCACHED as the memory type for PCI I/O mappings Thomas Petazzoni
2014-05-15 14:59 ` [PATCHv4 2/3] ARM: mm: add support for HW coherent systems in PL310 Thomas Petazzoni
2014-05-15 19:08 ` Rob Herring
2014-05-15 14:59 ` [PATCHv4 3/3] ARM: mvebu: implement L2/PCIe deadlock workaround Thomas Petazzoni
2014-05-16 6:08 ` Jason Cooper
2014-05-16 7:07 ` Thomas Petazzoni [this message]
2014-05-16 12:58 ` Jason Cooper
2014-05-16 13:21 ` Thomas Petazzoni
2014-05-16 19:09 ` Jason Cooper
2014-05-16 19:08 ` Jason Cooper
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=20140516090727.5264dc75@free-electrons.com \
--to=thomas.petazzoni@free-electrons.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox