public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Jeremy Higdon <jeremy@sgi.com>
Cc: Grant Grundler <grundler@parisc-linux.org>,
	Jesse Barnes <jbarnes@sgi.com>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	James.Bottomley@steeleye.com
Subject: Re: [RFC] Relaxed PIO read vs. DMA write ordering
Date: Fri, 9 Jan 2004 13:02:23 -0700	[thread overview]
Message-ID: <20040109200223.GA14165@colo.lackof.org> (raw)
In-Reply-To: <20040109071347.GB343099@sgi.com>

On Thu, Jan 08, 2004 at 11:13:47PM -0800, Jeremy Higdon wrote:
> What if the host/bridge sets the RO bit on a PIO read?  That would
> allow a PIO read response to bypass a DMA write.

*Any* bridge that is on the common path from CPU/Mem to PCI-X
can choose to implement RO anyway it likes. Even though such a
bridge may not use PCI-X, the entire system must honor the semantics
required by PCI/PCI-X one way or another. RO is optional IMHO.

> Now, maybe that
> doesn't make much sense with respect to PCI-X.  I think it's possible,
> though.  Or can the RO bit only be set by a device?

The ordering of transaction on the way to the device is not the obvious
problem here. It's the ordering of transactions originated by the device.
A read return is generated by the device on PCI-X since PCI-X supports
split transactions.

> In any case, if we can do a PIO read to one address space that flushes
> DMA ahead of it or another address space that does not, then you would
> need a separate version of readX, rather than an extra call to sync
> after the read.

That would be optimal yes.
But a functional pci_sync_consistent() implementation would consist
of a MMIO Read using the address space that enforces ordering.

As I pointed out earlier, the spec clearly states it's up to the
device to specify the ordering, not the device driver. The device
driver can only choose to enable the feature or not.

grant

  parent reply	other threads:[~2004-01-09 20:02 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
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 [this message]
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=20040109200223.GA14165@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=James.Bottomley@steeleye.com \
    --cc=jbarnes@sgi.com \
    --cc=jeremy@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    /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