This message is from the T13 list server.
Since the packet command using UDMA does not have this capability (one of Pat's original questions), one way you can look at this is to assume that the device knows it is a 16 bit wide data bus ATAPI device, and so if it has an ALLOCATION LENGTH for return data it should only return 4 bytes (2 words). You can always return fewer bytes than the ALLOCATION LENGTH, and this would be both legal for the device and safe (i.e. no possibility of 6 bytes getting to the host overflowing the ALLOCATION LENGTH size buffer). For old, silly software (the only type I'd think would be asking for 5 bytes to begin with) this should be find - the 5th byte in this case is the number of additional bytes in the possible returned INQUIRY data. At this point the host software will either finish happy with its 4 bytes, or will retry with a larger ALLOCATION LENGTH (like it should have done initially). Either way everything is legal and should work. The worse case is that if the host gives up at 4 bytes it does not get to see the additional INQUIRY return data. To return 6 bytes (three words) is to assume that the last byte falls away at some point - perhaps not an unreasonable practical assumption, but clearly violating the standard. For example, if this was a wide (16 bit) SCSI device I could not get away with 3 words transferred unless I followed up with an IGNORE WIDE RESIDUE message (which does not exist for ATA/ATAPI). 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). 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) 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). 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. Jim -----Original Message----- From: Hale Landis [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 6:03 PM To: [EMAIL PROTECTED] Subject: Re: [t13] a PIO example This message is from the T13 list server. On Thu, 13 Dec 2001 15:14:46 -0700, [EMAIL PROTECTED] wrote: >While the last DRQ packet might technically be allowed to be odd, >in practice it is probably not a good habit for a 'good' drive. But back to Pat's Inquiry command with the Alocation Lenght set to 5... I think I would expect a PACKET command that executes this Inquiry command in PIO mode to (mostly likely) have a single DRQ data block with a Byte Count of 5 even though we all know that 6 bytes will actually be transferred over the ATA interface. *** 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.
