All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: mm: dma: Update coherent streaming apis with missing memory barrier
Date: Thu, 24 Apr 2014 10:09:27 +0100	[thread overview]
Message-ID: <20140424090927.GB8521@arm.com> (raw)
In-Reply-To: <20140423171727.GK5649@arm.com>

On Wed, Apr 23, 2014 at 06:17:27PM +0100, Will Deacon wrote:
> On Wed, Apr 23, 2014 at 05:02:16PM +0100, Catalin Marinas wrote:
> > On Wed, Apr 23, 2014 at 10:02:51AM +0100, Will Deacon wrote:
> > > On Tue, Apr 22, 2014 at 09:30:27PM +0100, Santosh Shilimkar wrote:
> > > > writel() or an explcit barrier in the driver will do the job. I was
> > > > just thinking that we are trying to work around the short comings
> > > > of streaming API by adding barriers in the driver. For example
> > > > on a non-coherent system, i don't need that barrier because
> > > > dma_ops does take care of that.
> > > 
> > > I wonder whether we can remove those barriers altogether then (from the DMA
> > > cache operations). For the coherent case, the driver must provide the
> > > barrier (probably via writel) so the non-coherent case shouldn't be any
> > > different.
> > 
> > For the DMA_TO_DEVICE case the effect should be the same as wmb()
> > implies dsb (and outer_sync() for write). But the reason we have
> > barriers in the DMA ops is slightly different - the completion of the
> > cache maintenance operation rather than ordering with any previous
> > writes to the DMA buffer.
> > 
> > In the DMA_FROM_DEVICE scenario for example, the CPU gets an interrupt
> > for a finished DMA transfer and executes dma_unmap_single() prior to
> > accessing the page. However the CPU access after unmapping is done using
> > normal LDR/STR which do not imply any barrier. So we need to ensure the
> > completion of the cache invalidation in the dma operation.
> 
> I don't think we necessarily need completion, we just need ordering. That
> is, the normal LDR/STR instructions must be observed after the cache
> maintenance. I'll have to revisit the ARM ARM to be sure of this, but a dmb
> should be sufficient for that guarantee.

If we only do D-cache maintenance by MVA, the ARM ARM (both v7 and v8)
claims that these are ordered relative to any explicit load/stores to
the same address. So in theory we don't even need a DMB for unmapping
with DMA_FROM_DEVICE. But in practice, we may have the outer cache,
hence a DSB is required before the outer_sync() (we could move it there
though).

-- 
Catalin

  parent reply	other threads:[~2014-04-24  9:09 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 18:03 [PATCH] ARM: mm: dma: Update coherent streaming apis with missing memory barrier Santosh Shilimkar
2014-04-22 10:28 ` Will Deacon
2014-04-22 13:49   ` Santosh Shilimkar
2014-04-22 14:08     ` Arnd Bergmann
2014-04-22 14:36       ` Santosh Shilimkar
2014-04-22 19:53         ` Arnd Bergmann
2014-04-22 19:58           ` Santosh Shilimkar
2014-04-22 20:23             ` Arnd Bergmann
2014-04-22 20:30               ` Santosh Shilimkar
2014-04-23  9:02                 ` Will Deacon
2014-04-23 16:02                   ` Catalin Marinas
2014-04-23 17:17                     ` Will Deacon
2014-04-23 18:37                       ` Russell King - ARM Linux
2014-04-23 18:58                         ` Arnd Bergmann
2014-04-23 19:04                           ` Russell King - ARM Linux
2014-04-24 10:47                             ` Catalin Marinas
2014-04-24 11:15                               ` Russell King - ARM Linux
2014-04-24 11:21                                 ` Will Deacon
2014-04-24 13:38                                   ` Santosh Shilimkar
2014-04-24 14:09                                     ` Will Deacon
2014-04-24 14:44                                       ` Santosh Shilimkar
2014-04-24 19:12                                         ` Russell King - ARM Linux
2014-04-23 19:34                           ` Jason Gunthorpe
2014-04-24 10:58                           ` Will Deacon
2014-04-24 12:12                             ` Arnd Bergmann
2014-04-24 12:37                               ` Will Deacon
2014-04-24  9:54                         ` Catalin Marinas
2014-04-24 11:13                           ` Russell King - ARM Linux
2014-04-24  9:09                       ` Catalin Marinas [this message]
2014-04-24  9:16                         ` Russell King - ARM Linux
2014-04-24 10:13                           ` Catalin Marinas
2014-05-02 21:33                       ` Joel Fernandes
2014-05-06 10:01                         ` Will Deacon
2014-04-22 15:07     ` Catalin Marinas
2014-04-22 15:18       ` Santosh Shilimkar
2014-04-22 15:30         ` Catalin Marinas

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=20140424090927.GB8521@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 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.