This message is from the T13 list server.
>>> Hale Landis 04/15/02 12:15PM >>> > 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. Yes, on purpose, for the uttermost possible backwards compatibility. > Maybe you company is currently shipping devices that do this? Yes? No? Yes every Atapi device firmware written within a mile of me that shipped since I noticed the issue in November-ish 2001 does this ... but without flipping any particular xA1 IdentifyPacketDevice to say it does, since I've had difficulty explaining the issue clearly here. > Why do you need all 16-bits of the Byte Count registers to report a residue value that can only be 0 or 1? In UDma 2 this value is sometimes as high as 5. I know at length here before I've failed to explain clearly why, but it's a fact. > Isn't the device reporting ... at the end of the command a little late? Yes later than Pio, no not significantly later. Hardly anyone cares about residue until after the host copies Status In. For example, if the device went unexpectedly bus free i.e. BSY = DRQ = 0 without an INTRQ and C/D I/O = c i, then the residue doesn't matter. > 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? Hang, timeout, reset, retry is ok when the direction is wrong, just not preferred. Better late than never to have status to say this happened. In practice my fix for getting direction straight was (d) to write x1F3 with x80 In or x00 Out before o x1F7 xA0 Packet, to let the device see the direction the host wanted. If we want a device to react to a stimulus like that generally, we'll have to dream up an Ata op SetFeatures xEF setting to turn that reaction on. I'd first want to dig in further on the rumour that someone has a smarter way to reconcile UDma direction in advance. Without a further fix like (d), when the host & device disagree over direction, then UDma hangs quietly before clocking any data across the bus, yes. By silicon, devices vary over whether Pio/SwDma/MwDma hang or just quietly copy data into the void and garbage into memory. The more polite devices hang. > Yes every Atapi device firmware written within a mile of me that shipped since As yet this is an empty set. >This message is from the T13 list server. >My proposal (November?) last year was: > Does it have a T13 document number? Nope. Email. Does T13 have an email archive? Pat LaVarre x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Hale Landis 04/15/02 12:15PM >>> 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 ***
