linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] ARM: implement workaround for Cortex-A9/PL310/PCIe deadlock
Date: Mon, 7 Apr 2014 13:13:04 +0100	[thread overview]
Message-ID: <20140407121304.GD3360@arm.com> (raw)
In-Reply-To: <20140403141533.GP7528@n2100.arm.linux.org.uk>

On Thu, Apr 03, 2014 at 03:15:33PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 03, 2014 at 04:07:27PM +0200, Thomas Petazzoni wrote:
> > Any comments about the proposed patches? These are important for the
> > recent Armada 375/38x platforms and I'm sure will require a bit of
> > discussion. Moreover, one of the patch affects the L2 cache driver that
> > Russell is currently working on, so it would be nice if we could get
> > the discussion going soon.
> 
> Will is away for another week and a half.

And when he's back, I'm pretty sure he will be eager to look at the
PL310 code ;)

> There is an important point to be made about the L2 cache though - it is
> not possible to disable the "sync" at the L2 cache - any register write
> automatically invokes a sync before it is actioned, so avoiding the
> explicit sync doesn't stop them from happening, it just reduces the
> number which occur.

I agree, there is no way to disable the "sync". For this particular case
(a system erratum probably, I need to check) you need to make sure you
don't do PL310 and PCIe accesses by the CPU at the same time, otherwise
the system may deadlock.

However, on this Marvell board, the DMA is fully coherent so they don't
need L1 + L2 cache maintenance for such buffers. Due to hardware
coherency, they don't need the outer_sync() either for wmb() etc. So
far, you can treat this as an optimisation.

But the side-effect is that for most run-time operations (apart from
some power management or CPU hotplug) they won't need to touch any PL310
registers at all, and not even the outer_sync() via wmb(). This makes
it (nearly) impossible to hit the system erratum.

I don't remember why the SO memory is still needed for PCIe. I assume to
avoid posted writes but if we avoid PL310 accesses altogether, this may
not be an issue (well, unless the CPU power management code on this
platform needs to flush PL310 explicitly). I'll let you know when I find
out.

-- 
Catalin

  parent reply	other threads:[~2014-04-07 12:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-24 16:17 [PATCH 0/3] ARM: implement workaround for Cortex-A9/PL310/PCIe deadlock Thomas Petazzoni
2014-03-24 16:17 ` [PATCH 1/3] ARM: mm: allow sub-architectures to override PCI I/O memory type Thomas Petazzoni
2014-03-24 16:17 ` [PATCH 2/3] ARM: mm: add support for HW coherent systems in PL310 Thomas Petazzoni
2014-04-08 17:24   ` Catalin Marinas
2014-04-08 18:12     ` Thomas Petazzoni
2014-04-09 11:15       ` Catalin Marinas
2014-04-09 14:06       ` Catalin Marinas
2014-05-06 10:07         ` Thomas Petazzoni
2014-03-24 16:17 ` [PATCH 3/3] ARM: mvebu: implement L2/PCIe deadlock workaround Thomas Petazzoni
2014-04-03 14:07 ` [PATCH 0/3] ARM: implement workaround for Cortex-A9/PL310/PCIe deadlock Thomas Petazzoni
2014-04-03 14:15   ` Russell King - ARM Linux
2014-04-07  9:10     ` Thomas Petazzoni
2014-04-07 12:13     ` Catalin Marinas [this message]
2014-04-14 16:59       ` Will Deacon
2014-04-14 18:39         ` Thomas Petazzoni

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=20140407121304.GD3360@arm.com \
    --to=catalin.marinas@arm.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;
as well as URLs for NNTP newsgroup(s).