This message is from the T13 list server.
On Fri, 12 Apr 2002 18:28:00 -0600, Pat LaVarre wrote: >This message is from the T13 list server. >Me, the only T13 issue I see is that, to count bytes as well as AtapiPio, >AtapiDma, especially Atapi UDma, needs an analogue to the IgnoreWideResidue of >Scsi, for byte counts up to 2 * X + 1, where X is the pause indeterminacy that >rises with burst rate. Might be nice to have some English emphasing how nice >it is for Pci/Ide and other to-Ide bridges to bother to report how many bytes >clocked In, covered by the Crc, without being copied into memory. I'm going to try one more time and if that doesn't work this conversation will have to move offline and probably to the phone. You keep talking about this "2 * X + 1" problem at the end of Ultra DMA data bursts. I think this is the "residue" you keep talking about. The fact that you keep bring this up tells me you may not understand how ATA/ATAPI DMA works. So here goes... First, lets review ATA data transfer commands... For an ATA PIO command that transfers data, the data transfer is one or more PIO DRQ data blocks. Each data block is N*512 bytes (N>0). The entire data transfer for a command is nothing more than a data stream that is broken into chunks of N*512 bytes. For an ATA DMA command that transfers data, the data transfer is one or more DMA data bursts. DMA data bursts have nothing to do with the size of device data blocks. But the entire data transfer for a command is nothing more than a data stream that is broken into variable sized chunks of data. Now lets talk about ATAPI data transfer commands... For an ATAPI PIO command that transfers data, the data transfer is one or more PIO DRQ data blocks. These DRQ data blocks have nothing to do with the size of device data blocks and may be any size the device wants but shall not exceed the host specified Byte Count Limit size. But the entire data transfer for a command is nothing more than a data stream that is broken into chunks of variable size. If the entire data transfer for a command is an odd byte count then the odd byte and a pad byte shall be last word of the data transfer stream. For an ATAPI DMA command that transfers data, the data transfer is one or more DMA data burst. DMA data bursts have nothing to do with the size of device data blocks. But the entire data transfer for a command is nothing more than a data stream that is broken into chunks of variable size. If the entire data transfer for a command is an odd byte count then the odd byte and a pad byte shall be last word of the data transfer stream. Now lets look at an old example I posted... Many weeks ago I posted an example of a Ultra DMA data transfer command. I asked Pat to review and comment. I never did see any messages from Pat about those examples. So lets try again... ===begin example (Pat please review and comment) [This example is from an email dated 26 Jan 02.] I provided a number of examples some weeks ago (and I never saw any comment on them) but lets try another example here... Lets talk about a fast Ultra DMA mode where each time the receiver of the data attempts to terminate a DMA data burst the receiver gets 2 or 4 more data bytes... It doesn't matter what the command is or what the device block size is in this example... Lets just assume the total transfer will be 40 bytes and that several DMA data bursts are required... OK? The sender of the data could be the host or the device. When the device is ready to transfer data it asserts DMARQ and the host responds with DMACK and the first DMA data burst starts. The sender starts sending data bytes to the receiver. After receiving the first 10 bytes the receiver attempts to stop the DMA data burst but the sender sends 4 more data bytes before the DMA data burst actually ends. At this point the receiver has received the first 14 data bytes... that is 14 real data bytes, no pad bytes, no extra bytes of unknown origin... the receiver now has the first 14 data bytes. Now the sender wants to continue the transfer (there are 26 more bytes to transfer). In the second DMA data burst, after receiving 16 bytes the receiver attempts to stop the DMA data burst but the sender sends 2 more data bytes before the DMA data burst actually ends. At this point the receiver has received the first 32 data bytes (14 + 18)... that is 32 real data bytes, no pad bytes, no extra bytes of unknown origin... the receiver now has the first 32 data bytes. Now the sender wants to continue the transfer (there are 8 more bytes to transfer). In the third DMA data burst, after receiving 4 bytes the receiver attempts to stop the DMA data burst but the sender sends 4 more data bytes before the DMA data burst actually ends. Note that the sender would have stopped this transfer after sending 8 bytes anyway. At this point the receiver has received the all 40 bytes (14 + 18 + 8)... that is 40 real data bytes, the last byte might have been a pad byte, no extra bytes of unknown origin... the receiver now has all 40 data bytes. Pat... You keeping talking about "extra" data bytes... In the example above where are these "extra" data bytes? ===end example *** Hale Landis *** www.ata-atapi.com ***
