Re: [RFC] Relaxed PIO read vs. DMA write ordering

[Jeremy Higdon]

On Thu, Jan 08, 2004 at 11:44:06AM -0700, Grant Grundler wrote:
> On Thu, Jan 08, 2004 at 09:36:55AM -0800, Jesse Barnes wrote:
> > > BTW, Jesse, did you look at part II of Documentation/DMA-ABI.txt?
> > 
> > I remember seeing discussion of the new API, but haven't read that doc
> > yet.  Since most drivers still use the pci_* API, we'd have to add a
> > call there, but we may as well make the two APIs as similar as possible
> > right?
> 
> That would be my preference too.
> 
> I haven't studied "part II" closely enough to figure out if adding
> pci_sync_consistent() would outright replace much of the DMA-API
> interface. The main issue is cacheline ownership.
> 
> pci_sync_consistent() needs to indicate CPU wants ownership of outstanding
> cachelines vs IO device wanting to own them.
> SN2 doesn't care about the latter case since it's "mostly coherent".
> SN2 just needs to flush in-flight DMA and it's coherent again.
> But older non-coherent platforms do care.


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

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.

In theory, such a distinction would be useful for any platform that
uses separate paths for PIO read responses and DMA writes.  Perhaps
there is only one platform that has that feature?

jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/