This message is from the T13 list server.
TE Ooi and I have indicated in the past that "Wintel" boxes will not attempt to transfer more or less data than what is expected, meaning we'll set up a PRD that represents the amount of memory that correlates to the ATA command length. If anyone else is doing this, they are causing problems in their environments. Some devices will terminate requests early, but this is either flow control, or completion when the drive interrupts. When a drive completes in error, it tells us (unless there is some "secret society" thing I don't know of) via the status register of the error. When a drive is just not going to send any more (ATAPI is the biggest offender, with Mode Sense and Inquiry's being a big target, as well as some data transfers under a variety of conditions), the interrupt status is ok, but the host doesn't know the exact transfer count. Either way, we can deal with the problem in higher-level software that parses the data stream to get the return data (in the Mode Sense and Inquiry cases). Some folks have toyed with the idea of sending the drive a "big" transfer, then only setting up PRD's that represent a portion of it; I suggest against doing this. So no host should be attempting a mind-...game by tring to set the drive up to write more to the drive than the host is really ready to do. MKE. -----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.
