This message is from the T13 list server.
>On Sun, 14 Apr 2002 15:02:56 -0600, Pat LaVarre wrote: >This message is from the T13 list server. >Let me try one more time to connect with you over your Dma >examples. Can we agree traces such as the following two are >common? >Dma: > 3 "words" clocked In across the bus >Pio: > BSY DRQ C/D I/O = 0 1 D I > x1F5:1F4 ByteCount = x00:05 > 3 "words" clocked In across the bus Yes, 3 words (6 bytes) were moved on the ATA interface. I guess we can assume that only 5 bytes are useful data. We don't see the CDB here but I'll assume the SCSI command requested only 5 bytes. That is (maybe) confirmed by the PIO Byte Count value of 5. >I read your examples to be saying that in both of these traces >we see: > 3 "words" clocked In across the bus >I agree. Of course. Goes without saying. The bus is two bytes >wide. Yes. Yes... 3 words (6 bytes) were moved across the ATA interface, but... Q: How many of those bytes are valid/useful? A: See the SCSI CDB. Q: How many were copied from memory to the application program's I/O buffer? A: That depends on how the host hardware and software was designed and programmed. >I hear you saying that x86 folk copy In 3 "word"s only via 3 >REP's of INSW. I disagree. I see people using 2 REP's of INSW >followed by an IN AX followed by a MOV AL. I see 5 bytes copied >In, not 6, in Win98 & WinMe. What is the point here? On the ATA interface there were 3 IOR cycles to the ATA Data register and 6 bytes were transferred across the ATA interface. You are talking about OS driver stack implementation here. That has nothing to do with the ATA interface. I assume Win98 and WinME know to copy 5 bytes because: a) that is what the application program's SCSI CDB requested, or b) via some parameter to the OS device driver stack the driver(s) know the application program's I/O buffer is only 5 bytes. Doesn't matter if it is a) or b), this is a OS driver stack issue, not a T13 ATA interface issue. >I say this is a kind of double-buffering, one kind among many. Agree. >I hear you saying it's not a T13 problem if in the new Dma trace >the host copies In 6 bytes whereas in the similar old Pio trace >the host copies In 5 bytes. This same example in DMA would move 3 words or 6 bytes across the ATA interface. Nothing is different. And the OS device driver stack would need to know how many of those bytes should be placed into the application program's I/O buffer, again, by looking at the SCSI CDB or having some other information about the size of the application program's I/O buffer. There is no difference at the ATA interface. >I'm saying that Pio works and Dma doesn't is a T13 problem. Who >above he level of T13 cares if we're using Pio or Dma? Doesn't matter. In either case, PIO or DMA, the OS device driver stack must know how much data to move into the application program's I/O buffer. >It is the BSY DRQ C/D I/O ByteCount info that tells the host to >copy In just 5 bytes. T13, me included, we left I/O and >ByteCount out of Atapi Dma, whoops. No, in PIO the Byte Count tells the host to copy 6 bytes, and, oh by the way, the last byte is a pad byte. Yes, DMA doesn't tell the host that the last byte is a pad byte but why should that matter? The SCSI CDB tells the host how much data to expect. >Sure you're free to disagree. But are you telling me I am >incoherent? Can you not see my point of view? T13 used to pass >info across the bus that it passes across the bus no longer. Me >& friends, we were using that info. The information you seem to want was never in any ATA DMA data transfer protocol (SW, MW or UDMA). Nothing was removed by T13 because nothing was there to remove. I would say you made a bad design decision, that is, assuming the ATA protocols would give you this information in all data transfer protocols. It has always been the case that only by looking at the SCSI CDB (or the ATA hard disk command) can a host or device know how much data a command should transfer. You are trying to fix a problem you see in various host hardware and OS driver stack implementations by getting T13 to do something inappropriate, something you have failed to define so far. Maybe you proposed solution is really good and T13 will immediately adopted it. But so far no one knows what you want T13 to add or change. >Yes I am saying UDma has a further issue past that, yes I hear >you say no, but if we can I'd like to defer assessing my UDma >claim until we get consensus on at least how broken Atapi Dma is >as a Scsi-over-whatever mechanism for copying odd counts of >bytes. I think you further issue is the one of the receiver getting more data words after the receiver has signalled stop? This isn't an issue at all. As I said in a previous email, an ATA/ATAPI data transfer is a stream of data whose length is determine soley by the command being executed. That stream may be broken into more than one blocks or bursts due to a variety of reasons. Yes, ATA data transfers have those breaks at the N*512 byte boundaries. But for ATAPI PIO and DMA there are no predefined boundaries. But for all transfers we know that the last word of a block or burst is immediately followed by the first word in the next block or burst. An ATA/ATAPI receiver of data must be ready to accept block and burst boundaries at any time (especially for ATAPI PIO and DMA data transfers) but the receiver of data must also know that the command defines a single stream of data to be transferred (the point being that there are no extra bytes within the data stream, there are no bytes in the data stream that can be ignored and perhaps the last byte of the stream is a pad byte). Yes, this might make the design of a X-to-ATA/ATAPI bridge difficult. But that is life. ATA/ATAPI were not invented with X-to-ATA/ATAPI bridges in mind. The fact that such bridges are possible says there are some really good designers out there. And they are possible, it is just that the bridge device needs to perform valid operations on both the X and ATA/ATAPI interfaces and that may mean buffering data, rearranging data, mapping command A to command B or even to commands B and C, etc. And case it means the bridge must be a properly implemented ATA/ATAPI DMA host. I don't see T13 making any changes or additions to ATA/ATAPI DMA that could break existing implementations (that work OK). >My offer to connect by phone & pager remains open. Now that my taxes are nearly done, I should have time for a phone call tomorrow or Tuesday. These emails have been providing a break from the tax forms! *** Hale Landis *** www.ata-atapi.com ***
