This message is from the T13 list server.
Jim, In PIO for ATAPI you cannot have an odd residue until the last transfer of the command. Using these same rules the receiver would never have to face the issue of the odd bye residue until the command had ended, at which time issues like backing up DMA pointers becomes irrelevant (i.e. you have ended the DMA at that point, since everything is set up on a command by command basis). On a more general point, people seem to continue to confuse block transfers (in PIO) and bursts (in DMA) with commands. Precisely because you do not want to muddle around with the DMA channel during a command, these are very differently issues treated differently in both designs and protocol. Jim -----Original Message----- From: Jim Castleberry [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 8:48 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [t13] a fix for imprecise UDma residue? This message is from the T13 list server. Eschmann, Michael K wrote: >Only thing about the device sending a count before data is transferred is >not good error checking. If the DMA transfer dies before the count that we >indicate we want would be no different than saying nothing at all. A >post-check as Pat indicated would be better for DMA. If the host knows the count before the transfer can't it simply compare the expected to actual after the transfer and detect errors easily? A count before the burst would be better for bridges and DMA engines that aren't allowed to transfer the extra badding byte upstream on odd lengths, and that Pat wants to report accurate residues. And it's the same as the way PIO does it, so it's nothing new; I doubt there's any drive around that currently counts how many extra words the host sends/takes after the command is done. With a count afterward, the host has to buffer the last word of every read burst, go read the count, then commit the 1 or 2 last bytes. For writes it has to go read the count afterward and possibly back up it's residue and DMA pointers to account for the 0-4 extra words that might have gone over UDMA after the drive hit the end and did a Pause. Yuck. BTW, how did/does 1394's Tailgate handle this? That spec might be worth a read to see if there's a better way than changing drive specs and abandoning the installed base. jcastle Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
