On Wed, 20 Sep 2006 19:10:55 UTC, in fa.linux.kernel you wrote:
>
>On Wed, 20 Sep 2006, Alan Stern wrote:
>
>> I've heard that to insure proper synchronization it's necessary to flush
>> MMIO writes (writel, writew, writeb) to PCI devices by reading from the
>> same area. Is this equally true for I/O-space writes (inl, inw, inb)?
>> What about configuration space writes (pci_write_config_dword etc.)?
>>
>> Alan Stern
>
>Writes to I/O space are not queued through a FIFO so there is
>no need to flush the FIFO. Configuration space uses special
>configuration cycles which are handshakes with the devices. They
>cannot be queued, therefore don't need to be flushed either.
>
>Flushing PCI space writes shouldn't be done until you want
>whatever you've been planning to happen __now__. Otherwise
>the advantages of queued writes go away. In other words, one
>should NOT attach a read to every PCI space write! Typically
>use of the flushing read might be in the case of setting up
>hardware for a DMA transfer. You write all the data, source
>address, destination address, byte-count, DMA type, etc., then
>after the last instruction, the one should should start the DMA,
>you issue a read.
Are there ever any issues with out-of-order writes from the posting
buffer on supported architectures? I can (barely) imagine a device
that has the register with the start bit lower in the register address
space than the count/address registers. Out-of-order writes from
the cache/non-fifo/posting buffer (maybe to assemble a burst) could
make the occasional mess.
Just wondering,
Bill
--
William D Waddington
[email protected]
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
