Date: Wed, 21 May 1997 15:25:44 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: garycorc@idt.net, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards Message-ID: <19970521152544.25788@x14.mi.uni-koeln.de> In-Reply-To: <199705211236.WAA23416@godzilla.zeta.org.au>; from Bruce Evans on Wed, May 21, 1997 at 10:36:31PM %2B1000 References: <199705211236.WAA23416@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 21, Bruce Evans <bde@zeta.org.au> wrote: > I tried using 1 ins[bwl](port, dummyaddr, 1000) instead of 1000 inb's. > The results were (perhaps not surprisingly) similar. They were within 1 > nsec for de0, varied a lot with the access size for the crtc, and were > within 1 nsec for ins[bw] from wdc0 and twice as large for insl from > wdc0 (1510 nsec instead of 755 nsec). The latter is a bit surprising > - my wdc0 is configured for and uses 32-bit accesses and has a 16MB/s > transfer speed, yet 4 bytes per 1510 nsec is only 2.65 MB/s. I guess > the wdc data register is only valid when there is real data available :-). I'm not sure I understand what happens, but it might be like this: The PCI bus specs limit the time a single transfer may take to 16 bus cycles. If a device can't send deliver valid data within that time, it must back off. (If a device knows it can't deliver data with little delay, then it should acknowledge the address phase, but immediately signal a retry is necessary. This makes the bus available for other bus masters, and when the host to PCI bridge requests the same data again, a few hundred nanoseconds later, the slow chip should have prepared it in its output buffer and should respond fast to this repeated request.) Anyway, if the IDE chip finds it can't deliver any data, then it will signal an abort (and probably set a flag in a status register). The PCI IDE interface will try to retrieve the second 16bit word thereafter, if you are doing a DWORD register access, and this will fail after the same time. I guess that is ithe reason you see exactly twice delay in the insl case ... The delay of some 750ns is equivalent to 25 PCI bus cycles. This is slightly more than the allowed 16 wait cycles, but is in line with the other delays yor found (11 clocks best case). If the 25 cycles are 10 cycles for the fastests possible inb() and 15 wait cycles, then this looks self-consistent at least :) I guess the 32bit IDE hardware is just to dumb to know it need not try to fetch the second 16bits after the first transfer failed to deliver any data ... > >2) The PCI bus may have been "parked" at some other > > bus master. In order to give the output drivers > > of the current master time to go into a high > > impedance state, one cycle of delay is added. > > 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 ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970521152544.25788>