This message is from the T13 list server.
Pat, I misinterpreted your proposal to report the bytes transferred (as is done today in PIO), not the byte "residue." This eliminates the SCSI command size limit problem, but requires drivers to use this new protocol - the same drivers that cannot implement things correctly today. Jim -----Original Message----- From: Hale Landis [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 11:16 AM To: [EMAIL PROTECTED] Subject: Re: [t13] Proposal to 'fix' ATAPI DMA This message is from the T13 list server. On Mon, 15 Apr 2002 11:38:00 -0600, Pat LaVarre wrote: >This message is from the T13 list server. >My proposal (November?) last year was: Does it have a T13 document number? >a) Flip a bit in the op xA1 IdentifyPacketDevice to say you are device that >bothers to report the bus residue, even for Dma, not just for Pio. OK. >b) Report the bus residue in x1F5:1F4 ByteCount at >BSY DRQ C/D I/O = 0 0 c i StatusIn time. >c) Also report x1F3 SectorNumber = x80 to say the device copied data In. >Report x1F3 SectorNumber = x00 to say the device copied data Out. Why do you need all 16-bits of the Byte Count registers to report a residue value that can only be 0 or 1? Isn't the device reporting the data direction at the end of the command a little late? Hasn't the command failed, probably with some timeout error, long before the end of the command is reached? >In all the Atapi device silicon I know, this is a firmware change only, no >silicon change required. Silicon that automagically reports Good status >despite the Atapi Data Fifo being not empty would have to learn to check for >that (rare) condition. The registers you want to use are currently defined as having an 'na' value at the end of a PACKET command. Your company could just put this information there a 'vendor specific' data. Maybe you company is currently shipping devices that do this? Yes? No? *** Hale Landis *** www.ata-atapi.com ***
