linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Cassel <niklas.cassel@axis.com>
To: David Miller <davem@davemloft.net>
Cc: pavel@ucw.cz, peppe.cavallaro@st.com, alexandre.torgue@st.com,
	Jose.Abreu@synopsys.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/4] net: stmmac: use correct barrier between coherent memory and MMIO
Date: Sat, 3 Mar 2018 00:28:53 +0100	[thread overview]
Message-ID: <20180302232853.GA11108@axis.com> (raw)
In-Reply-To: <20180302.095411.1270630534912987342.davem@davemloft.net>

On Fri, Mar 02, 2018 at 09:54:11AM -0500, David Miller wrote:
> From: Pavel Machek <pavel@ucw.cz>
> Date: Fri, 2 Mar 2018 10:20:00 +0100
>

Hello Pavel, David

> >> This barrier cannot be a simple dma_wmb(), since a dma_wmb() is only
> >> used to guarantee the ordering, with respect to other writes,
> >> to cache coherent DMA memory.
> > 
> > Could you explain this a bit more (and perhaps in code comment)?

Have a look at:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/memory-barriers.txt?h=v4.16-rc1#n1913

AFAICT, a dma_wmb() can only be used to guarantee that the
writes to cache coherent memory (e.g. memory allocated with
dma_alloc_coherent()) before the dma_wmb() will be performed
before the writes to cache coherent memory after the dma_wmb().

Since most of our writes are simply writing new buffer addresses
and sizes to TDES0/TDES1/TDES2/TDES3, and since these TX DMA
descriptors have been allocated with dma_alloc_coherent(),
a dma_wmb() should be enough to e.g. make sure that TDES3
(which contains the OWN bit), is written after the writes to
TDES0/TDES1/TDES2.

However, the last write we do is "DMA start transmission",
this is a register in the IP, i.e. it is a write to the cache
incoherent MMIO region (rather than a write to cache coherent memory).
To ensure that all writes to cache coherent memory have
completed before we start the DMA, we have to use the barrier
wmb() (which performs a more extensive flush compared to
dma_wmb()).

So the only place where we have to use a wmb() instead
of a dma_wmb() is where we have a write to coherent memory,
followed by a write to cache incoherent MMIO.
The only obvious place where we have this situtation is
where we write the OWN bit immediately followed by a write
to the "DMA start transmission" register.

Note that this also matches how it's done in other other drivers:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/amd/xgbe/xgbe-dev.c?h=v4.16-rc1#n1638

There is already a comment describing the barrier in
stmmac_xmit() and stmmac_tso_xmit() that says:
/* The own bit must be the latest setting done when prepare the
 * descriptor and then barrier is needed to make sure that
 * all is coherent before granting the DMA engine.
 */
However, if you want, we could mention wmb() explicitly in this comment.

> > 
> > Ensuring other writes are done before writing the "GO!" bit should be
> > enough, no?
> 
> Indeed, the chip should never look at the descriptor contents unless
> the GO bit is set.
> 
> If there are ways that it can, this must be explained and documented
> since it is quite unusual compared to other hardware.
> 
> > (If it is not, do we need heavier barriers in other places, too?)
> 
> Right.

I hope that my explaination above has cleared any potential confusion.


Best regards,
Niklas

  reply	other threads:[~2018-03-02 23:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 21:47 [PATCH net-next 0/4] stmmac barrier fixes and cleanup Niklas Cassel
2018-02-26 21:47 ` [PATCH net-next 1/4] net: stmmac: ensure that the MSS desc is the last desc to set the own bit Niklas Cassel
2018-02-26 21:47 ` [PATCH net-next 2/4] net: stmmac: use correct barrier between coherent memory and MMIO Niklas Cassel
2018-03-02  9:20   ` Pavel Machek
2018-03-02 14:54     ` David Miller
2018-03-02 23:28       ` Niklas Cassel [this message]
2018-03-07 15:32         ` David Miller
2018-03-07 17:21           ` Niklas Cassel
2018-03-07 17:42             ` David Miller
2018-03-07 18:09               ` Niklas Cassel
2018-03-08  9:05               ` Pavel Machek
2018-02-26 21:47 ` [PATCH net-next 3/4] net: stmmac: ensure that the device has released ownership before reading data Niklas Cassel
2018-02-26 21:47 ` [PATCH net-next 4/4] net: stmmac: make dwmac4_release_tx_desc() clear all descriptor fields Niklas Cassel
2018-02-27 19:28 ` [PATCH net-next 0/4] stmmac barrier fixes and cleanup David Miller

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=20180302232853.GA11108@axis.com \
    --to=niklas.cassel@axis.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=alexandre.torgue@st.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=peppe.cavallaro@st.com \
    /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).