This message is from the T13 list server.
I agree with Hale's message by the way. Jim PS In SCSI/MMC the consistent terminology used here is ALLOCATION LENGTH (you shall transfer up to that amount, but not over it) and TRANSFER LENGTH (you shall transfer exactly that length). The "shall" is deliberate and indicates a standards requirement. I cannot find any command where a length indicator can be exceeded (once again, this violates SAM). Also, ALLOCATION LENGTH is used for all some DATA IN commands, but no DATA OUT commands (at least I could not find any). Transfer LENGTH is used for all DATA OUT commands, and some DATA IN commands. -----Original Message----- From: Hale Landis [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 5:58 PM To: T13 List Server Subject: Re: [t13] to UDma from SwDma - for a 16-bit Ide Dma engine? This message is from the T13 list server. On Wed, 12 Dec 2001 10:05:11 -0700, Pat LaVarre wrote: >Can we agree ... >The API between a PC and a 16-bit Ide Dma engine is a >request to clock across at most N * 2 bytes either in or out. PC being x86 based PCI bus system? If so, the PC software builds a PRD list for the DMA engine that describes the memory buffer for the data. Yes, the PRD list can be thought of as defining the maximum data transfer length but it is the ATA or ATAPI device that determines the amount of data that will be transferred. For ATA devices it is easy for the PC side to know the exact size of the transfer that is about to happen and build the appropriate PRD list. For most ATAPI data transfers the same is also possible. Here are the actual possibilities: A) The PRD list defines exactly the number of bytes the device will transfer. The most common case. In this case the host side and the device side will reach the end of the transfer at the "same time". And this is true for both MW DMA and U-DMA. B) The PRD list is shorter. (Big buzzer in the sky again: BAD HOST.) The device will appear to hang BSY=1 status with DMARQ asserted. A reset is required to get out of this mess. This is true for both MW DMA and U-DMA. C) The PRD list is longer. The device will stop transferring data and end the command. This is true for both MW DMA and U-DMA. For a "write" command the host DMA engine might transfer an extra few bytes before it detects that the device wants to terminate that last DMA burst. The device will ignore these bytes (but for U-DMA they are included in the last DMA burst's CRC). >All other things being equal, with UDma, a 16-bit >Ide Dma engine will sometimes clock more "word"s >across the bus than with SwDma. *ONLY* in case C and *ONLY* for "write" commands. No big deal, this just means the host provided a bigger data buffer than the data the device wants for the "write" command. (This could be a confused host.) >This will happen whenever the device stops data out >prematurely, unless the Dma engine had coincidentally, >independently, chosen to delay for a turnaround time >just when the device decided to stop data out. So what? It is no big deal as long as the host is not confused and thinks the command it send to the device should have transferred all the data in the host buffer. But since there are no main-stream products that have an indeterminate data transfer length for a "write" command I really don't see the problem. The host should always know the amount of data that the device will want for the "write" command and there is no reason for the host to specify a bigger data buffer (so case C really should not happen). >These coincidences that discourage extra "word"s may >happen most often at mutually agreed block boundaries. There are no "block" boundaries in DMA data transfers. There is the total amount of data that the current command will transfer. That data could be transferred in a single DMA burst or in hundreds or thousands of DMA bursts that have nothing to do with "block" boundaries. Pat: Is this what is confusing you? Do you think that a DMA burst is always equal to a media data block? They are not, there is *NO* relationship between this two things. >I mean now to focus on the case of UDma Data Out >when the receiver chooses to move less than the >max permitted by the command, especially when this >hapens without the receiver reporting an ERR. If you mean a "write" command then this would be case B. Broken/bad host. I know of *NO* "write" command on any device where the amount of data to the transferred to the device is indeterminate. The host has no reason not to provide the correct amount of data for every "write" command. In this case I would not expect an error from the device because the device will be hung with DMARQ asserted waiting for the rest of the data transfer to happen. Hope this helps. *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
