Jeff Garzik wrote:
>
> I plan to put the following wisdom into pci.txt. As told to me from
> Alan, who claims that Gerard Roudier is the real expert. Gerard in
> turns claims nothing more than actually reading the PCI spec. :)
>
> 1) PCI will delay writes, group writes together but it will not re-order
> them or let reads pass writes. [thus, a readl() will cause a PCI flush
> of all delayed writes]
This would assume that the CPU itself does not reorder reads and writes?
We know that Pentium uses 'processor order'. But do any of the
processors which Linux currently supports do external read/write
reordering? If so, would this alter the order as seen by the PCI
bridge?
> 2) [What happens when two CPUs two to MMIO spaces at the "same time"?]
> Both writes will occur. The ordering will be the CPU ordering. It may
> turn them both into a single burst write if they are adjacent and the
> ordering is lower->higher
I'd like to know what happens in the other direction, where CPU accesses
and PCI DMA are both fiddling with main memory (courtesy of
pci_alloc_consistent()).
Suppose, for example, that the CPU writes two words to memory. Does the
PCI DMA see them in the correct order (non-Pentium), or must some
special barriers be used?
What happens the PCI DMA wants to write to an address which is currently
dirty, within a CPU cache?
What happens when PCI DMA wants to read an address which is currently
dirty, within a CPU cache?
What happens when PCI DMA writes to an address which is currently clean
within a CPU cache?
Why doesn't PCI SIG take %$&!^%$% credit card orders so I can get their
spec without having to futz with a fax machine?
-- -akpm-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:19 EST