From: catalin.marinas@arm•com (Catalin Marinas)
To: linux-arm-kernel@lists•infradead.org
Subject: PL310 errata workarounds
Date: Mon, 17 Mar 2014 17:29:44 +0000 [thread overview]
Message-ID: <20140317172943.GI24070@arm.com> (raw)
In-Reply-To: <20140317153738.GB21483@n2100.arm.linux.org.uk>
On Mon, Mar 17, 2014 at 03:37:38PM +0000, Russell King - ARM Linux wrote:
> On Mon, Mar 17, 2014 at 10:04:20AM -0500, Rob Herring wrote:
> > On Sun, Mar 16, 2014 at 6:52 AM, Russell King - ARM Linux
> > <linux@arm•linux.org.uk> wrote:
> > > The MCPM stuff is another issue: what the conditions are there I've
> > > no idea, but it looks like other CPUs will be running when it calls
> > > outer_cache_flush(). MCPM commentry claims that this will be
> > > "harmless" and I just had to laugh at that - even with this workaround
> > > enabled, it doesn't fix the problem on L2C-310 R2P0 as the workaround
> > > implementation only works on R3P0!
> >
> > For MCPM, is there even a platform that has a PL310 used as an L3? I
> > suppose architecturally it is possible, but in reality it is probably
> > not something that's ever been tested.
>
> I have no idea about MCPM
I assume that the MCPM comment about outer_cache_flush() being harmless
is because it is assumed to be a no-op. In the mach-vexpress/dcscb.c
file, there is a v7_exit_coherency_flush() prior to outer_flush_all().
While it looks like the right way, the comment for
v7_exit_coherency_flush() states that ldrex/strex no longer work after
the call.
You could do with a lock-less outer_flush_all(), even though it is a
background operation assuming there is no race (single CPU running). I
think your big clean-up series is already hiding outer_flush_all() under
the L2 disable function.
> > This would help with contention in readl/writel, but you still have
> > most all the overhead of a spinlock. I'm not sure which is the bigger
> > component: lock contention or all the loads, stores and dsb/dmbs
> > associated with the lock.
>
> Using the arch r/w locks is not that heavy, and doesn't have the problem
> that interrupts are locked out during much of the L2 maintanence. Even
> with arch r/w locks, the L2 cache ops don't show up much in perf, compared
> to the existing implementation where they show quite highly.
>
> The only issue is we'd only be able to use this optimisation when we
> aren't running in IRQ context anyway, which I think isn't that great a
> restriction on it.
IIRC Will had a patch for this but I don't remember whether it showed
any improvements (I guess not since the patch hasn't been pushed).
> > Isn't using by way ops potentially broken if you are running a secure
> > OS? If linux is doing a by way operation and the secure OS does range
> > operations, someone is going to crash on an abort. I suppose no one
> > sees this due to the limited function of secure OSs.
>
> Let's cover that should it happen - a secure OS should check the status
> of the L2 hardware before issuing any cache operation anyway for exactly
> this reason (you can always read from the L2 registers to check whether
> any operation is in progress.)
But between the secure OS check and the actual operation, Linux could
start a background one (the SMP case). If this happens, the hardware
generates an error signal, I guess this translates to an external abort
(I haven't tried it but it doesn't look to safe for the secure world).
--
Catalin
next prev parent reply other threads:[~2014-03-17 17:29 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 14:48 PL310 errata workarounds Russell King - ARM Linux
2014-03-14 15:01 ` Russell King - ARM Linux
2014-03-14 16:02 ` Rob Herring
2014-03-14 17:57 ` Russell King - ARM Linux
2014-03-14 19:14 ` Rob Herring
2014-03-14 20:32 ` Russell King - ARM Linux
2014-03-19 21:22 ` Marek Vasut
2014-03-19 21:35 ` Rob Herring
2014-03-19 21:46 ` Russell King - ARM Linux
2014-03-19 21:54 ` Marek Vasut
2014-03-16 11:52 ` Russell King - ARM Linux
2014-03-17 15:04 ` Rob Herring
2014-03-17 15:37 ` Russell King - ARM Linux
2014-03-17 17:29 ` Catalin Marinas [this message]
2014-03-17 19:44 ` Russell King - ARM Linux
2014-03-17 21:09 ` Nicolas Pitre
2014-03-17 21:14 ` Russell King - ARM Linux
2014-03-17 21:54 ` Nicolas Pitre
2014-03-16 15:29 ` Russell King - ARM Linux
2014-03-17 14:00 ` Rob Herring
2014-03-17 14:40 ` Russell King - ARM Linux
2014-03-18 11:22 ` *READ THIS IF YOUR SOC HAS A L2 CACHE* PL310 auxctrl settings Russell King - ARM Linux
2014-03-28 12:51 ` Maxime Coquelin
2014-03-28 13:02 ` Russell King - ARM Linux
2014-03-28 13:32 ` Maxime Coquelin
2014-03-18 17:26 ` PL310 errata workarounds Russell King - ARM Linux
2014-03-19 21:52 ` Marek Vasut
2014-03-19 22:51 ` Russell King - ARM Linux
2014-03-19 23:05 ` FEC ethernet issues [Was: PL310 errata workarounds] Marek Vasut
2014-03-20 4:01 ` Marek Vasut
2014-03-20 22:27 ` Fabio Estevam
2014-03-20 23:06 ` Russell King - ARM Linux
2014-03-21 0:24 ` Troy Kisky
2014-03-21 1:18 ` Russell King - ARM Linux
2014-03-21 1:36 ` Fabio Estevam
2014-03-21 1:43 ` Fabio Estevam
2014-03-21 16:37 ` Bernd Faust
[not found] ` <CANBf9eNZB+BVBDkgWNxxGs-ndQ-mYCc6+bfVdS-8T-QLpSZ3GA@mail.gmail.com>
2014-03-21 17:32 ` Russell King - ARM Linux
2014-03-23 11:38 ` Bernd Faust
2014-03-23 13:44 ` Russell King - ARM Linux
2014-03-24 17:57 ` robert.daniels at vantagecontrols.com
2014-03-24 20:21 ` Marek Vasut
2014-03-24 22:37 ` robert.daniels at vantagecontrols.com
2014-03-24 23:44 ` Russell King - ARM Linux
2014-03-25 1:02 ` Marek Vasut
2014-03-25 23:10 ` Russell King - ARM Linux
2014-03-26 0:11 ` Russell King - ARM Linux
2014-04-01 9:26 ` Russell King - ARM Linux
2014-04-01 14:00 ` Eric Nelson
2014-04-01 17:29 ` Russell King - ARM Linux
2014-04-01 18:11 ` Eric Nelson
2014-04-02 2:26 ` fugang.duan at freescale.com
2014-04-01 19:38 ` robert.daniels at vantagecontrols.com
2014-04-01 22:51 ` Russell King - ARM Linux
2014-04-02 0:37 ` robert.daniels at vantagecontrols.com
2014-04-02 3:19 ` fugang.duan at freescale.com
2014-04-02 8:59 ` Russell King - ARM Linux
2014-04-02 9:40 ` fugang.duan at freescale.com
2014-04-02 10:46 ` Russell King - ARM Linux
2014-04-02 11:33 ` fugang.duan at freescale.com
2014-04-02 16:51 ` Russell King - ARM Linux
2014-04-03 2:41 ` fugang.duan at freescale.com
2014-04-03 8:56 ` Russell King - ARM Linux
2014-04-03 9:55 ` fugang.duan at freescale.com
2014-04-03 10:32 ` Russell King - ARM Linux
2014-04-03 13:36 ` Shawn Guo
2014-04-03 13:45 ` Russell King - ARM Linux
2014-04-03 14:00 ` Shawn Guo
2014-04-04 20:21 ` robert.daniels at vantagecontrols.com
2014-04-29 9:26 ` Jaccon Bastiaansen
[not found] ` <CAGzjT4d8H6YE6P6A1E4aHiPAenJFvZH01LHXaNzVwhF2MRBvWQ@mail.gmail.com>
2014-05-02 11:41 ` Russell King - ARM Linux
2014-05-08 9:23 ` Jaccon Bastiaansen
2014-03-21 15:50 ` PL310 errata workarounds Frank Li
2014-03-21 17:12 ` Russell King - ARM Linux
2014-03-17 16:32 ` Russell King - ARM Linux
2014-03-17 16:51 ` Russell King - ARM Linux
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=20140317172943.GI24070@arm.com \
--to=catalin.marinas@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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