|Brett Glass||May 20, 1997 10:19 am|
|Brett Glass||May 20, 1997 11:51 am|
|Dan Welch||May 20, 1997 1:30 pm|
|Randy Berndt||May 20, 1997 2:14 pm|
|Brett Glass||May 20, 1997 5:11 pm|
|Dan Welch||May 20, 1997 7:00 pm|
|John-Mark Gurney||May 20, 1997 7:43 pm|
|Dan Welch||May 20, 1997 7:57 pm|
|Dan Welch||May 20, 1997 8:12 pm|
|Gary T. Corcoran||May 20, 1997 8:50 pm|
|Michael Smith||May 20, 1997 9:04 pm|
|Michael Smith||May 20, 1997 9:33 pm|
|Bruce Evans||May 20, 1997 10:15 pm|
|Gary T. Corcoran||May 20, 1997 11:38 pm|
|Bruce Evans||May 21, 1997 12:05 am|
|John-Mark Gurney||May 21, 1997 12:17 am|
|Poul-Henning Kamp||May 21, 1997 12:21 am|
|John-Mark Gurney||May 21, 1997 12:43 am|
|Bruce Evans||May 21, 1997 1:09 am|
|Bruce Evans||May 21, 1997 1:16 am|
|Bruce Evans||May 21, 1997 2:48 am|
|Dan Welch||May 21, 1997 2:54 am|
|Stefan Esser||May 21, 1997 3:16 am|
|Poul-Henning Kamp||May 21, 1997 3:25 am|
|Andrew Stesin||May 21, 1997 4:10 am|
|Bruce Evans||May 21, 1997 5:36 am|
|Dan Welch||May 21, 1997 6:02 am|
|Stefan Esser||May 21, 1997 6:25 am|
|Brett Glass||May 21, 1997 6:39 am|
|Bruce Evans||May 21, 1997 6:44 am|
|Brett Glass||May 21, 1997 6:59 am|
|Brett Glass||May 21, 1997 7:04 am|
|Brett Glass||May 21, 1997 7:09 am|
|Poul-Henning Kamp||May 21, 1997 7:27 am|
|Stefan Esser||May 21, 1997 9:26 am|
|Poul-Henning Kamp||May 21, 1997 9:31 am|
|Poul-Henning Kamp||May 21, 1997 9:33 am|
|Rob Schofield||May 21, 1997 4:47 pm|
|Michael Smith||May 21, 1997 9:15 pm|
|Michael Smith||May 21, 1997 9:20 pm|
|Brett Glass||May 21, 1997 10:10 pm|
|Brett Glass||May 21, 1997 10:19 pm|
|Gary Palmer||May 21, 1997 11:11 pm|
|John-Mark Gurney||May 21, 1997 11:32 pm|
|Michael Smith||May 21, 1997 11:37 pm|
|Michael Smith||May 21, 1997 11:38 pm|
|Poul-Henning Kamp||May 22, 1997 12:10 am|
|Brett Glass||May 22, 1997 5:11 pm|
|Wm Brian McCane||May 24, 1997 5:15 pm|
|Subject:||Re: isa bus and boca multiport boards|
|From:||Stefan Esser (se...@FreeBSD.ORG)|
|Date:||May 21, 1997 9:26:14 am|
On May 21, Poul-Henning Kamp <ph...@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:
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 ...