linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: mm: dma: Update coherent streaming apis with missing memory barrier
Date: Wed, 23 Apr 2014 13:34:54 -0600	[thread overview]
Message-ID: <20140423193454.GA10076@obsidianresearch.com> (raw)
In-Reply-To: <6414220.SShvCHLvZQ@wuerfel>

On Wed, Apr 23, 2014 at 08:58:05PM +0200, Arnd Bergmann wrote:

> PCI guarantees this, but I have seen systems in the past (on
> PowerPC) that would violate them on the internal interconnect: You
> could sometimes see the completion DMA data in the descriptor ring
> before the actual user data is there. We only ever observed it in
> combination with an IOMMU, when the descriptor address had a valid
> IOTLB but the data address did not.

Ordering in PCI-E gets a bit fuzzy when you talk about internal order
within the host bridge, but AFAIK, re-ordering non-relaxed PCI-E
writes is certainly a big no-no.. It breaks the entire
producer/consumer driver model..

> Another problem is MSI processing. MSI was specifically invented to avoid
> having to check an MMIO register for a DMA completion that as a side-effect
> flushes pending DMAs from the same device. This breaks down if the MSI
> packet gets turned into a level interrupt before it reaches the CPU's
> coherency domain, which is likely the case on the dw-pcie controller that
> comes with its own MSI block.

I recently implemented a PCI-E to AXI bridge HW that does MSI in an
AXI environment and it requires waiting for all AXI operations
associated with prior PCI-E packets to complete and be acked back to
the bridge before sending an MSI edge over to the GIC.

Unlike PCI, AXI provides a write completion ack back to the initiator,
which can only be sent by the completor once the transaction is
visible to all other initiators.

A bridge must similarly serialize other TLPs: eg a series of posted
writes with the relaxed ordering bit set can be pipelined into AXI,
but once a non-relaxed TLP is hit, the bridge must wait for all the
prior writes to be ack'd before forwarding the non-relaxed one.

Not doing this serialization would be the root cause of problem like
you described above in PPC - where the IOMMU path takes longer than
the non-IOMMU path so the non-relaxed completion write arrives too
soon.

IMHO, if someone builds a PCI-E bridge that doesn't do this, then it's
MSI support is completely broken and should not be used. Delivering a
MSI interrupt before data visibility completely violates requirements
in PCI-E for transaction ordering.

It is also important to note that even level interrupts require bridge
serialization. When a non-relaxed read-response TLP is returned the
bridge must wait for all AXI writes to be ack'd before forwarding the
read response. Otherwise writes could be buffered within the
interconnect and still not be visible to the CPU while the read
response 'passes' them.

Jason

  parent reply	other threads:[~2014-04-23 19:34 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 [this message]
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
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=20140423193454.GA10076@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.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).