This message is from the T13 list server.
Thanks everyone for helping explore why We have so many ways to inject delay into UDma data transfers ... Re terminating a burst to read a Pio register ... I remember hearing some talk of teaching a host to read x1F2 & x03 I/O C/D during a Dma data transfer to discover which way (In to the host or Out from the host) the device was trying to copy the data ... I don't know that anyone ever used that technique - it carries risks like <a> not talking like Microsoft and <b> not improving the situation with devices that keep BSY set then and <c> ... I've been told that by spec and in practice, UDma by default hangs if the device & the host disagree over direction, which to my eye is an ok response to such a provocation, though not best of class. (Best of class is to discover the trouble and report it promptly, rather than waiting for a timeout and reset.) x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Hale Landis 04/10/02 03:21PM >>> This message is from the T13 list server. On Wed, 10 Apr 2002 14:00:23 -0700, Ooi, Thien Ern wrote: >This message is from the T13 list server. >Yes, the ATA interface is indeed returned to the "PIO State" whenever the >device registers are accessed. Because the (intel) host adapter does not >make any assumption on what the status or any other register should be >during a UDMA burst, it always runs the "PIO" cycle to the device. But why do this? From day one of this interface we know that during the execution of a DMA data transfer command a device should have status of BSY=1 (yes, some devices have status of BSY=0 DRQ=1 but that doesn't matter, either status tells the host the device is busy). So why should a host adapter terminate a DMA data burst in progress when the host does a read of one of the device registers? Why not just tell return fake data of 80H and let the DMA data burst continue uninterrupted? To me this is just all part of the sad state of current ATA host adapter designs. Except for a few efforts ourside of the main stream, no real attention has been paid to how ATA host adapters can be improved. Worse yet, little attention has been paid to how inefficient today's stupid host adapters are. Another question: Can you give me one good reason why (5 years ago!) the host side should not be able to use a PRD list for PIO data transfers and have the host adapter preform the equivalent of the x86 REP INSx/OUTSx instructions? Given the popularity of ATA/ATAPI and all the improvements done in device designs there is no excuse for the host adapter side of the interface to be in such a sad state! (Oh yea, I know I will hear all the same old excuses... Well ATA is obsolete... Soon to be replaced by <you name it>... Microsoft won't support the change... It would cost too much... blah blah blah... We can't spend money on this but gee wiz we have the money to design 1394 interfaces, USB interfaces, <you name it> interfaces, but no money for ATA... only the most popular storage device interface on this planet.) *** Hale Landis *** www.ata-atapi.com ***
