From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: l2x0: make it possible to disable outer sync from DT
Date: Mon, 14 Dec 2015 13:32:38 +0000 [thread overview]
Message-ID: <20151214133237.GG6992@arm.com> (raw)
In-Reply-To: <CACRpkdayPdJDKPh=6vH5p5gWCu1uetBVdbEJz8Pvw79bujmQrg@mail.gmail.com>
On Mon, Dec 14, 2015 at 02:30:53PM +0100, Linus Walleij wrote:
> On Thu, Dec 10, 2015 at 3:32 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Thu, Dec 10, 2015 at 03:14:15PM +0100, Linus Walleij wrote:
> >> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> >> index d181b7c4c522..aae7387acbdb 100644
> >> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> >> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> >> @@ -75,6 +75,7 @@ Optional properties:
> >> specified to indicate that such transforms are precluded.
> >> - 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).
> >> +- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
> >
> > I'm not sure what this means from a HW perspective. The "outer sync"
> > operation is Linux terminology and doesn't show up in the TRM for L220.
> >
> > What is the (integration? HW?) bug that we're trying to avoid the effect
> > of? It sounds like we should be describing that.
> >
> > We should at least have a better definition of what this means we must
> > avoid.
>
> So this code is a bit ancient, and we're trying to migrate it to device tree.
>
> It was inspired by this board file patch from Arnd:
> http://marc.info/?l=linux-arm-kernel&m=144846938616893&w=2
>
> Then I go back and dig in the code and I find this:
>
> commit 2503a5ecd86c002506001eba432c524ea009fe7f
> Author: Catalin Marinas <catalin.marinas@arm.com>
> Date: Thu Jul 1 13:21:47 2010 +0100
>
> ARM: 6201/1: RealView: Do not use outer_sync() on ARM11MPCore
> boards with L220
>
> RealView boards with certain revisions of the L220 cache controller (ARM11*
> processors only) may have issues (hardware deadlock) with the
> recent changes to
> the mb() barrier implementation (DSB followed by an L2 cache
> sync). The patch
> redefines the RealView ARM11MPCore mandatory barriers without the
> outer_sync()
> call.
>
> Cc: <stable@kernel.org>
> Tested-by: Linus Walleij <linus.walleij@stericsson.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> And that is as much as it says.
>
> It is working around a hardware lockup in some core tiles. Is it
> enough if I add this
> to the explanation or do we need to send Catalin or Will down in the archives
> to read netlists? ;)
/me delegates to Rutland.
Mark -- still want a better definition? ;)
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/2] ARM: l2x0: make it possible to disable outer sync from DT
Date: Mon, 14 Dec 2015 13:32:38 +0000 [thread overview]
Message-ID: <20151214133237.GG6992@arm.com> (raw)
In-Reply-To: <CACRpkdayPdJDKPh=6vH5p5gWCu1uetBVdbEJz8Pvw79bujmQrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Dec 14, 2015 at 02:30:53PM +0100, Linus Walleij wrote:
> On Thu, Dec 10, 2015 at 3:32 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Thu, Dec 10, 2015 at 03:14:15PM +0100, Linus Walleij wrote:
> >> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> >> index d181b7c4c522..aae7387acbdb 100644
> >> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> >> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> >> @@ -75,6 +75,7 @@ Optional properties:
> >> specified to indicate that such transforms are precluded.
> >> - 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).
> >> +- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
> >
> > I'm not sure what this means from a HW perspective. The "outer sync"
> > operation is Linux terminology and doesn't show up in the TRM for L220.
> >
> > What is the (integration? HW?) bug that we're trying to avoid the effect
> > of? It sounds like we should be describing that.
> >
> > We should at least have a better definition of what this means we must
> > avoid.
>
> So this code is a bit ancient, and we're trying to migrate it to device tree.
>
> It was inspired by this board file patch from Arnd:
> http://marc.info/?l=linux-arm-kernel&m=144846938616893&w=2
>
> Then I go back and dig in the code and I find this:
>
> commit 2503a5ecd86c002506001eba432c524ea009fe7f
> Author: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
> Date: Thu Jul 1 13:21:47 2010 +0100
>
> ARM: 6201/1: RealView: Do not use outer_sync() on ARM11MPCore
> boards with L220
>
> RealView boards with certain revisions of the L220 cache controller (ARM11*
> processors only) may have issues (hardware deadlock) with the
> recent changes to
> the mb() barrier implementation (DSB followed by an L2 cache
> sync). The patch
> redefines the RealView ARM11MPCore mandatory barriers without the
> outer_sync()
> call.
>
> Cc: <stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Tested-by: Linus Walleij <linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
> Signed-off-by: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
>
> And that is as much as it says.
>
> It is working around a hardware lockup in some core tiles. Is it
> enough if I add this
> to the explanation or do we need to send Catalin or Will down in the archives
> to read netlists? ;)
/me delegates to Rutland.
Mark -- still want a better definition? ;)
Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-12-14 13:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 14:14 [PATCH 1/2] ARM: l2x0: make it possible to disable outer sync from DT Linus Walleij
2015-12-10 14:14 ` Linus Walleij
2015-12-10 14:20 ` Arnd Bergmann
2015-12-10 14:20 ` Arnd Bergmann
2015-12-14 13:23 ` Linus Walleij
2015-12-14 13:23 ` Linus Walleij
2015-12-10 14:32 ` Mark Rutland
2015-12-10 14:32 ` Mark Rutland
2015-12-14 13:30 ` Linus Walleij
2015-12-14 13:30 ` Linus Walleij
2015-12-14 13:32 ` Will Deacon [this message]
2015-12-14 13:32 ` Will Deacon
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=20151214133237.GG6992@arm.com \
--to=will.deacon@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.