From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
Feng Kan <fkan-qTEPVZfXA3Y@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Subject: Re: [PATCH v2] ARM: realview: basic device tree implementation
Date: Thu, 22 May 2014 17:49:16 +0200 [thread overview]
Message-ID: <5057707.jNCXlqf9dH@wuerfel> (raw)
In-Reply-To: <20140522144503.GA27931-5wv7dgnIgG8@public.gmane.org>
On Thursday 22 May 2014 15:45:03 Catalin Marinas wrote:
> On Thu, May 22, 2014 at 09:31:37AM +0100, Arnd Bergmann wrote:
> > commit 42c4dafe803dcad82980fd8b0831a89032156f93
> > Author: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
> > Date: Thu Jul 1 13:22:48 2010 +0100
> >
> > ARM: 6202/1: Do not ARM_DMA_MEM_BUFFERABLE on RealView boards with L210/L220
> >
> > RealView boards with certain revisions of the L210/L220 cache controller
> > may have issues (hardware deadlock) with the mandatory barriers (DSB
> > followed by an L2 cache sync) when ARM_DMA_MEM_BUFFERABLE is enabled.
> > The patch disables ARM_DMA_MEM_BUFFERABLE for these boards.
> >
> > 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>
>
> Looking through the L220 errata document, I think this relates to 425331
> which says that a cache sync can deadlock the system if the write buffer
> is not empty.
Hmm, but isn't the write buffer empty here because we have just issued
a dsb()?
> By making the DMA memory Strongly Ordered, we avoid the
> L220 write buffer. In addition to the above commit, we also had
> 2503a5ecd86c (ARM: 6201/1: RealView: Do not use outer_sync() on
> ARM11MPCore boards with L220).
Ah, so this also stands in the way of multiplatform realview :(
> The above only solves the issue for coherent DMA allocations. Streaming
> DMA requires additional changes to cache-l2x0.c but they are all weird
> and depend on how the L2x0 is wired (for example, using SWP to access
> the L2x0 registers works on one RealView board but not on another).
> Anyway, I don't think we have any streaming DMA used on these RealView
> boards.
Yes, I think that is correct. MMCI, SSP and serial could all use
DMA but are not configured to do it.
> If we only use the DMA coherent buffers for CLCD on these boards, we
> don't really need the outer_sync() either so we could go back to
> bufferable DMA memory (strangely enough, this L2 cache workaround looks
> similar to Marvell's PCI+PL310 problem where we want to avoid
> outer_sync()).
Ah, so you think we can add another hook to NULL out outer_cache.sync
per platform?
Arnd
--
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:[~2014-05-22 15:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 22:08 [PATCH v2] ARM: realview: basic device tree implementation Linus Walleij
[not found] ` <1399586896-16906-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-05-09 10:44 ` Arnd Bergmann
[not found] ` <201405091244.02066.arnd-r2nGTMty4D4@public.gmane.org>
2014-05-22 7:41 ` Linus Walleij
[not found] ` <CACRpkdb8c=k3Ky=TisNdzycc3owJsNSQmSTu03RR5E0QvE0KZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 8:31 ` Arnd Bergmann
2014-05-22 13:04 ` Linus Walleij
[not found] ` <CACRpkdYE0Fb+HezqgDbVcqQmWwn7QL2+RWSRyAigv2qcMp2qFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 13:38 ` Arnd Bergmann
2014-05-22 14:45 ` Catalin Marinas
[not found] ` <20140522144503.GA27931-5wv7dgnIgG8@public.gmane.org>
2014-05-22 15:49 ` Arnd Bergmann [this message]
2014-05-22 16:09 ` Catalin Marinas
2014-05-22 18:09 ` Nicolas Pitre
[not found] ` <alpine.LFD.2.11.1405221406100.17310-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>
2014-05-22 18:26 ` Arnd Bergmann
2014-05-22 18:39 ` Nicolas Pitre
[not found] ` <alpine.LFD.2.11.1405221431370.17310-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>
2014-05-22 20:25 ` Arnd Bergmann
2014-05-22 18:52 ` Linus Walleij
[not found] ` <CACRpkdZX=UFhMfUn68hA+s2FLGRYy_dmjRng_fHtAQEhah0oRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 20:35 ` Arnd Bergmann
2014-05-29 9:38 ` Linus Walleij
2014-05-22 22:34 ` Sebastian Hesselbarth
[not found] ` <537E7B83.4020900-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-29 9:44 ` Linus Walleij
[not found] ` <CACRpkdap1U19EiULnq11udhY91UnnNu_-5MnLby3idbdjzBj4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-29 10:10 ` Sebastian Hesselbarth
[not found] ` <53870787.3030202-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-29 14:13 ` Linus Walleij
[not found] ` <CACRpkdYVe+++Qb-CWrWwM1zDHxNqmpE0CFzp959Q40Zqb5sUEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-29 14:47 ` Sebastian Hesselbarth
2014-05-22 13:17 ` Rob Herring
[not found] ` <CAL_JsqLN_f1uvrY6w7J7ZcR9pfM0_XKYMQ5YU8F4yAcMW+oDGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 13:30 ` Linus Walleij
[not found] ` <CACRpkdaqsVUDA+6NC=EQmxcnDAnJEfPNYoptrEv=nq=eZEbA_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-22 13:36 ` Arnd Bergmann
2014-05-28 22:47 ` Rob Herring
2014-05-22 13:41 ` 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=5057707.jNCXlqf9dH@wuerfel \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=Marc.Zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=Mark.Rutland-5wv7dgnIgG8@public.gmane.org \
--cc=Pawel.Moll-5wv7dgnIgG8@public.gmane.org \
--cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=fkan-qTEPVZfXA3Y@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.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