LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: akepner@sgi.com,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Tony Luck <tony.luck@intel.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Jes Sorensen <jes@sgi.com>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	Roland Dreier <rdreier@cisco.com>,
	David Miller <davem@davemloft.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, Mark Nelson <mdnelson@au1.ibm.com>
Subject: Re: [PATCH 1/3 v3] dma: document dma_{un}map_{single|sg}_attrs() interface
Date: Tue, 18 Mar 2008 12:08:59 +1100	[thread overview]
Message-ID: <1205802540.8195.30.camel@concordia.ozlabs.ibm.com> (raw)
In-Reply-To: <20080314052158.GG24794@colo.lackof.org>

[-- Attachment #1: Type: text/plain, Size: 3113 bytes --]

On Thu, 2008-03-13 at 23:21 -0600, Grant Grundler wrote:
> On Fri, Mar 14, 2008 at 03:30:29PM +1100, Michael Ellerman wrote:
> ...
> > > +DMA_ATTR_BARRIER is a barrier attribute for DMA.  DMA to a memory 
> > > +region with the DMA_ATTR_BARRIER attribute forces all pending DMA 
> > > +writes to complete, and thus provides a mechanism to strictly order 
> > > +DMA from a device across all intervening busses and bridges.  This 
> > > +barrier is not specific to a particular type of interconnect, it 
> > > +applies to the system as a whole, and so its implementation must 
> > > +account for the idiosyncracies of the system all the way from the 
> > > +DMA device to memory. 
> > 
> > You say a "DMA to a memory region with the DMA_ATTR_BARRIER attribute
> > forces all pending DMA writes to complete". Does it force _all_ DMA
> > writes to complete, or just writes to the region, or just writes coming
> > from devices?
> 
> Yes to "_all_ DMA writes". re-read the second sentence.

Yeah, just checking. 

> > What if something is writing to a device?
> 
> aka MMIO writes. Not defined and in general unrelated. AFAIK, no
> version of PCI has ordering rules for traffic going in opposite
> directions. I'm 99% sure about this but haven't reviewed any
> PCI docs in about 2 years.

I'll take you word for it :)  But there's also non-PCI things between
the device and the cpu, so anything's potentially possible.

> On a related note, I always think of MSI/MSI-X as DMA Writes.
> Michael's got me thinking we need to explicitly state that.
> In "normal" use, the device will not issue an MSI until after
> the "completion DMA write" has been issued and thus the MSI/MSI-X
> transactions are NOT subject to the ordering requirement...but
> that's not exactly true. We don't want the MSI to ever
> pass the "completion DMA write".
> 
> Do we need to state the platform interconnect can NOT allow
> successive DMA writes to pass the ordered DMA writes?
> Or state MSI DMA writes are implied to be to an "ordered DMA region"?
> Both statements?

I think the 2nd at least. If MSIs can pass the DMAs they're signalling
completion for then they're no better than LSI, the driver will still
need to go check the DMA has finished somehow. 

> > Does DMA_ATTR_BARRIER have any effect on reads?
> 
> It could but it's not defined to. :)
> I thought about this before but wanted to keep the document short.
> 
> Perhaps two things should be done to address this:
> 1) rename this to DMA_ATTR_WRITE_BARRIER
> 2) state it has no explicit effect on DMA Reads.
> 
> If someone needs that changed in the future, we can then
> define how reading from a region will trigger ordering rules.

I'd vote for 1), that way if someone comes up with a semantic for
read/write/both we will have sensible flag names.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2008-03-18  1:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-28  3:24 akepner
2008-02-29  2:45 ` Michael Ellerman
2008-02-29 18:25   ` Grant Grundler
2008-02-29 18:37     ` James Bottomley
2008-03-01  2:56       ` Benjamin Herrenschmidt
2008-03-01  3:11         ` Jesse Barnes
2008-03-01  7:18         ` Grant Grundler
2008-03-05 18:13       ` akepner
2008-03-05 19:02         ` Jesse Barnes
2008-03-06  6:01         ` Michael Ellerman
2008-03-12  1:19           ` akepner
2008-03-14  4:13             ` Grant Grundler
2008-03-14  4:30             ` Michael Ellerman
2008-03-14  5:21               ` Grant Grundler
2008-03-14 16:40                 ` Jesse Barnes
2008-03-18  1:08                 ` Michael Ellerman [this message]
2008-03-20  0:32               ` akepner
2008-02-29 21:23   ` akepner

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=1205802540.8195.30.camel@concordia.ozlabs.ibm.com \
    --to=michael@ellerman.id.au \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akepner@sgi.com \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=grundler@parisc-linux.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdnelson@au1.ibm.com \
    --cc=randy.dunlap@oracle.com \
    --cc=rdreier@cisco.com \
    --cc=tony.luck@intel.com \
    --subject='Re: [PATCH 1/3 v3] dma: document dma_{un}map_{single|sg}_attrs() interface' \
    /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

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).