linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: Clarifying dma_wmb behavior in presence of non-coherent masters and outer caches
Date: Fri, 29 Jun 2018 18:46:23 +0100	[thread overview]
Message-ID: <20180629174622.GB20909@arm.com> (raw)
In-Reply-To: <1530292490.22468.76.camel@pengutronix.de>

On Fri, Jun 29, 2018 at 07:14:50PM +0200, Lucas Stach wrote:
> Am Freitag, den 29.06.2018, 17:22 +0100 schrieb Will Deacon:
> > You're right that cacheability and shareability are different things. For
> > the purposes of ordering and coherence, we care about shareability. Normal
> > non-cacheable is outer-shareable (which is a superset of inner-shareable),
> > so DMB OSH is sufficient to order accesses to that buffer from the
> > perspective of all observers.
> 
> Can you point me to something where this mapping from normal, non-
> cacheable to outer-sharable is defined? Why is there a distinction
> between OSH and SY in the barriers, if all non-coherent masters are in
> the outer sharable domain?
> 
> /me is still confused

Hopefully my reply to Russell will help you here. The distinction between
OSH and SY is for handling masters that are not coherent at all, even when
using non-cacheable mappings. But as I mentioned to Russell, I think this
is largely theoretical and nobody builds systems like this.

> >  Since we use Normal non-cacheable mappings
> > for non-coherent DMA buffers (and there is no such thing as a
> > system-shareable memory type), then these barriers are sufficient to provide
> > ordering in this case too.
> > 
> > Ideally, we'd limit the DMA barriers to the inner-shareable domain when
> > dealing with coherent devices, but there's no way to determine that from
> > the barrier macros.
> > 
> > Lucas -- did changing the shareability of the DMA barriers actually solve
> > your problem?
> 
> There isn't enough data at this point to conclusively answer this. But
> reading the code, this struck me as being odd enough to warrant some
> clarifications from experts.

Have you checked that you have bit 22 set in the PL310 aux ctrl register?

Will

  reply	other threads:[~2018-06-29 17:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 12:28 Clarifying dma_wmb behavior in presence of non-coherent masters and outer caches Lucas Stach
2018-06-29 14:25 ` Russell King - ARM Linux
2018-06-29 16:19   ` Lucas Stach
2018-06-29 16:22   ` Will Deacon
2018-06-29 16:48     ` Russell King - ARM Linux
2018-06-29 17:43       ` Will Deacon
2018-06-29 18:01         ` Russell King - ARM Linux
2018-07-02 13:49         ` Lucas Stach
2018-07-02 17:45           ` Will Deacon
2018-07-06 12:26             ` Will Deacon
2018-07-09  6:20               ` Oleksij Rempel
2018-09-13 13:17                 ` Will Deacon
2018-09-13 14:09                   ` Oleksij Rempel
2018-07-09  9:45               ` Lucas Stach
2018-06-29 17:14     ` Lucas Stach
2018-06-29 17:46       ` Will Deacon [this message]
2018-07-02  9:58         ` Lucas Stach

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=20180629174622.GB20909@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).