mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Matthew Wilcox <willy@debian.org>
Cc: Jesse Barnes <jbarnes@sgi.com>,
	linux-pci@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org,
	jeremy@sgi.com
Subject: Re: [RFC] Relaxed PIO read vs. DMA write ordering
Date: Wed, 7 Jan 2004 15:21:42 -0700	[thread overview]
Message-ID: <20040107222142.GB14951@colo.lackof.org> (raw)
In-Reply-To: <20040107190206.GK17182@parcelfarce.linux.theplanet.co.uk>

On Wed, Jan 07, 2004 at 07:02:06PM +0000, Matthew Wilcox wrote:
> So we want a pci_set_relaxed() macro / function() to set this bit
> (otherwise dozens of drivers will start to try to set the bit themselves,
> badly).  If this bit *isn't* set, setting the bit in the transaction will have
> no effect, right?

I think that's correct if the platform chipset ignores RO signal
by default. I'm not real comfortable with that assumption though.
I want the driver to advertise to PCI services the intent to use
RO capability.

> How about always setting the bit in readb() and having a readb_ordered()
> which doesn't set the bit in the transaction?

I was under the impression the driver can't control RO for
each transaction though. The PCI-X device controls which
transactions set RO "signal" in the PCI-X command on read-return.
The Read-Return is a seperate transaction from the Read-Request.

If anyone has data that specific devices are "smart" and set/clear
RO appropriately, it would be safe to enable RO for them.

On HP ZX1, the "Allow Relaxed Ordering" is only implemented for outbound
DMA/PIO Writes *while they pass through the ZX1 chip*. Ie RO bit settings
don't explicitly apply since we aren't talking about PCI-X bus transactions
even though the system chipset needs to honor PCI-X rules.

> That way, drivers which
> call pci_set_relaxed() have the responsibility to verify they're not
> relying on these semantics and use readb_ordered() in any places that
> they are.

if new variants of readb() are ok, then yours sounds better.

But I wasn't too keen on introducing readb variants to solve what
looks like a DMA flushing problem. I've come to the conclusion
that systems which implement (and enable) RO for inbound DMA are
effectively not coherent. The data the CPU expects to be visible is not.

DMA-mapping.txt already has support (pci_dma_sync_xx() or pci_dma_unmap_xx())
to deal with common forms off non-coherence and syncronize caches
for streaming mappings but not for consistent mappings.
DMA-ABI.txt (2.6 only) has a method to handle non-coherent systems and
I have to reread/study it to see if the provided interface is sufficient
for the case of relaxed ordering.  Jesse, have you looked at this already?

hth,
grant

> No doubt you're going to smack this idea down by telling me what SN2
> firmware currently does ...
> 
> -- 
> "Next the statesmen will invent cheap lies, putting the blame upon 
> the nation that is attacked, and every man will be glad of those
> conscience-soothing falsities, and will diligently study them, and refuse
> to examine any refutations of them; and thus he will by and by convince 
> himself that the war is just, and will thank God for the better sleep 
> he enjoys after this process of grotesque self-deception." -- Mark Twain

  reply	other threads:[~2004-01-07 22:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-07 17:58 Jesse Barnes
2004-01-07 19:02 ` Matthew Wilcox
2004-01-07 22:21   ` Grant Grundler [this message]
2004-01-07 23:07     ` Jesse Barnes
2004-01-07 23:27       ` Greg KH
2004-01-07 23:56         ` Jesse Barnes
2004-01-08  0:34           ` Jesse Barnes
2004-01-08  0:08         ` Jeremy Higdon
2004-01-08 10:01         ` Jes Sorensen
2004-01-08  6:38       ` Grant Grundler
2004-01-08 16:23         ` Leonid Grossman
2004-01-08 17:39           ` Jesse Barnes
2004-01-08 17:54           ` Christoph Hellwig
2004-01-08 19:48             ` Leonid Grossman
2004-01-08 17:36         ` Jesse Barnes
2004-01-08 18:44           ` Grant Grundler
2004-01-09  7:13             ` Jeremy Higdon
2004-01-09 19:51               ` Jesse Barnes
2004-01-09 23:15                 ` Jesse Barnes
2004-01-09 20:02               ` Grant Grundler
2004-01-11 14:34             ` James Bottomley
2004-01-09  7:39           ` Jochen Friedrich
2004-01-09 20:27             ` Grant Grundler
2004-01-09 22:12               ` Ivan Kokshaysky
2004-01-07 22:58   ` Jesse Barnes

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=20040107222142.GB14951@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=jbarnes@sgi.com \
    --cc=jeremy@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=willy@debian.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

all inboxes | Powered by JetHome®