Date: Wed, 21 May 1997 18:26:34 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Poul-Henning Kamp <phk@dk.tfs.com> Cc: Bruce Evans <bde@zeta.org.au>, garycorc@idt.net, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards Message-ID: <19970521182634.47161@x14.mi.uni-koeln.de> In-Reply-To: <2292.864224884@critter>; from Poul-Henning Kamp on Wed, May 21, 1997 at 04:28:04PM %2B0200 References: <19970521152544.25788@x14.mi.uni-koeln.de> <2292.864224884@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 21, Poul-Henning Kamp <phk@dk.tfs.com> wrote: > > >> Clearly some magic (like data available :-) is required to > >> get burst mode. Do you thing 300+ nsec is typical for > >> non-data registers? > > > >Well, there is no such thing as burst mode I/O in PCI :) > >Burst transfers are only defined for memory accesses ... > > Isn't I/O and Memory symmetrical in PCI ? No, not at all! The original PCI concept tolerated I/O ports only to allow legacy drivers to be used with PCI cards, that emulate some common ISA card (like my PCI NE2000 :). There is a note somewhere in the PCI standards docs, that mentions 8086 real mode programs may need to use port mapped I/O. (I've only once heard about some (old) PCI motherboard assigning an address below 1MB to some PCI device. This prevents DOS driver access to those memory mapped registers, and you want to use port I/O under DOS for that reason.) There are three memory read "commands" and two memory write "commands", BTW. (PCI uses the byte enables to carry a 4bit command in the address phase. There are no seperate lines to signal memory/port or read/write as they are found on most other buses.) The three read commands are: read read-line read-multiple The two write commands are: write write-and-invalidate The read command is used for single word transfers or for short bursts. If a full cache line worth of data is to be read, the read-line command is used. For two or more cache-line transfers, the read-line command is to be used. The write-and-invalidate command is to be used, if a complete cache line is to be written by some bus master. It signals to the CPU and chip set, that the contents of this cache line may be discarded if present int the primary and/or secondary cache instead of a write back that would be necessary if only part of the cache line was to be updated by the bus master. The write-and-invalidate does also allow for all but the first snoop cycles to be suppressed, since the CPU is known to not have that line in the cache, thereafter. Intel x86 CPU's don't write-allocate (the K5(?) and K6 in certain situations, though), and the cache line must be filled with the new values written by the bus-master, before the CPU can read or write them. The read-line and read-and-invalidate may reduce the number of snoop cycles, too, but their primary purpose is to make PCI to PCI bridges prefetch data from devices that are known to tolerate read-ahead. The access latency caused by a PCI to PCI bridge is multiple cycles (i never tried to measure the effect, but my estimate is some 4 to 6 PCI clocks or 120ns to 180ns), and without the read-ahead feature, this penalty had to be payed for each single DWORD transfered ... Burst modes are required to increment the targets address register by 4bytes after each transfer. There exists no burst transfer to (or from) a constant address, and that is a reason that bursts are not supported for port I/O. There is an assumption, that data can be read-ahead, and then just thrown away, if it is not accepted by the intiator of the transferi (for example because the bus-master run out of time, i.e. the latency timer expired). The initiator will in such a case restart the transfer as soon as it gets the PCI bus granted again, and it will restart the transfer at an address that is 4 higher per DWORD received. This can't be easily implemented with port mapped buffers, and for that reason no port burst transfers have been defined ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970521182634.47161>