All of lore.kernel.org
 help / color / mirror / Atom feed
From: jbarnes@sgi.com (Jesse Barnes)
To: Grant Grundler <grundler@parisc-linux.org>
Cc: Matthew Wilcox <willy@debian.org>,
	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:07:12 -0800	[thread overview]
Message-ID: <20040107230712.GB6837@sgi.com> (raw)
In-Reply-To: <20040107222142.GB14951@colo.lackof.org>

On Wed, Jan 07, 2004 at 03:21:42PM -0700, Grant Grundler wrote:
> > 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.

My understanding is that you need both.  And if we used the
pci_enable_relaxed() routine, we'd have to add a check to readX() for it
so that we don't accidentally set the RO bit in the transaction when the
command word has it clear.

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

I don't know of any that do it automatically...

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

So this wouldn't be helpful for your chipset then.

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

Ahh... that's a bit of a stretch of the definition of non-coherence I
think, but it might be close enough to use the sync semantics.

> 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

Right, that's another option--adding a pci_sync_consistent() call.

> 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?

All of them are pretty easy enough to do...  so I see our options as one
of the following:

  1) add pcix_enable_relaxed() and read_relaxed() (read() would always be
     ordered)
  2) add pcix_enable_relaxed() and read_ordered() (read() would be
     relaxed after the pcix_enable_relaxed() call)
  3) add pcix_enable_relaxed() and pci_sync_consistent() (read() would
     be relaxed after the pcix_enable_relaxed() call)

Thanks,
Jesse

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

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-07 17:58 [RFC] Relaxed PIO read vs. DMA write ordering Jesse Barnes
2004-01-07 19:02 ` Matthew Wilcox
2004-01-07 22:21   ` Grant Grundler
2004-01-07 23:07     ` Jesse Barnes [this message]
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=20040107230712.GB6837@sgi.com \
    --to=jbarnes@sgi.com \
    --cc=grundler@parisc-linux.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.