This message is from the T13 list server.
Pat, If you don't understand 1, then maybe you're not really understanding ALLOCATION LENGTH? It's always been legal to send back fewer bytes, and in this case the last byte just tells you if there is more INQUIRY date the host COULD ask for if it wanted to. So there is no problem. Or put another way, what do you think the problem is in this case? On 2, Hale tells us that this is already specified in ATAPI (i.e. the thing issuing the command should know about this). Certainly if I got back 6 bytes from a device when I requested 5 I would drop the last byte, even if a standard did not tell me that was the ting to do. And on the third, there is no DATA OUT issue at all (as I've gone over before). Providing 1 or 2 are not satisfactory, the greatest "residue" you can ever get for a successful command is 1 byte. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 12:29 PM To: [EMAIL PROTECTED] Subject: RE: [t13] a PIO example - Jim's three conceived Dma fixes This message is from the T13 list server. > So in these cases I think we either: > 1) settle on not getting the last byte > (which is fine whenever we are discussing > ALLOCATION LENGTHs, not TRANSFER LENGTHs). I don't follow, as posted separately, in the thread titled "fewer back is always ok? say again?". > 2) get the extra byte, but rely on something somewhere > to drop the extra byte (as a uP based bridge > which cracked the command would do) Yes. I'm asking for the protocol to clue the host in: let the device tell the host when to drop the byte or not, no matter whether the host is uP based or not. > 3) add something like IGNORE WIDE RESIDUE > for packet commands using DMA. > I'd suggest that if DMA is being used then > set Byte Count High to 0 and Byte count Low to 0 > (indicating no pad) or 1 (indicating a pad byte). Yes. Except I think after UDma Out we may have as many as X * 2 + 1 pad bytes that have clocked out, with X rising with burst rate, with X = 2 for UDma 33. > Of course, one of the bits someplace else could be used > if there are some reasons to not use Byte Count > (today no value for Byte Count is defined when DMA is used, > so there could be legacy issues). > > I'd also specify that this is looked at > after the DMA is complete > (so that the device has loads of time to set the bit, > in firmware if needed). > This should mirror IGNORE WIDE RESIDUE nicely. Yes. How about an xEC/A1 Identify bit to say whether the x1F5:1F4 AtapiByteCount (aka AtaCylinder) registers at BSY:DRQ=0:0 C/D:I/O = x03 StatusIn time contain indeterminate garbage or a typically zero byte residue? Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
