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
next prev 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$(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