Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [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@arm.com>

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@arm.com>
> > 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@stericsson.com>
> >     Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> >     Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> 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

  reply	other threads:[~2014-05-22 15:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-08 22:08 [PATCH v2] ARM: realview: basic device tree implementation Linus Walleij
2014-05-09 10:44 ` Arnd Bergmann
2014-05-22  7:41   ` Linus Walleij
2014-05-22  8:31     ` Arnd Bergmann
2014-05-22 13:04       ` Linus Walleij
2014-05-22 13:38         ` Arnd Bergmann
2014-05-22 14:45       ` Catalin Marinas
2014-05-22 15:49         ` Arnd Bergmann [this message]
2014-05-22 16:09           ` Catalin Marinas
2014-05-22 18:09           ` Nicolas Pitre
2014-05-22 18:26             ` Arnd Bergmann
2014-05-22 18:39               ` Nicolas Pitre
2014-05-22 20:25                 ` Arnd Bergmann
2014-05-22 18:52           ` Linus Walleij
2014-05-22 20:35             ` Arnd Bergmann
2014-05-29  9:38               ` Linus Walleij
2014-05-22 22:34     ` Sebastian Hesselbarth
2014-05-29  9:44       ` Linus Walleij
2014-05-29 10:10         ` Sebastian Hesselbarth
2014-05-29 14:13           ` Linus Walleij
2014-05-29 14:47             ` Sebastian Hesselbarth
2014-05-22 13:17 ` Rob Herring
2014-05-22 13:30   ` Linus Walleij
2014-05-22 13:36     ` Arnd Bergmann
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@arndb.de \
    --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