This message is from the T13 list server.
> 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 Yes please. Volunteers, anyone? Or even just URLs? > A count before the burst would be better for bridges > and DMA engines that aren't allowed > to transfer the extra padding byte upstream on odd lengths, Yes. Somewhat better for the host, somewhat tougher for the device. If we extended the protocol to supply a count before each burst, it would take us years, maybe forever, before we could persuade Windows to pause the Dma to go sample and eventually sum that count. That means lots of devices would ship with creative reactions to any host that injected, for example, UDma terminations, to see the count for each burst. Maybe we'd rather make Dma work more like Pio - but I think we'll fail. The rule of Break No Working Code will keep us from exchanging burst lengths between host & device in the middle of the normal block read/write that doesn't has this problem any time the host & the device know some factor larger than the indeterminacy that divides evenly into the block length. I'd be ok with putting two options into the standard for accurately counting residues, let the device report whether it supports either, both, or neither options, and let us all experience what works out in plug 'n play. I trust we agree requiring a legacy device to learn to report the actual total of all bursts before any bursts is impractical. If the device is going to duplicate Pio behaviour bug-for-bug, the device has to do things like trying to write blocks but stopping with a full buffer after the first error. > it's the same as the way PIO does it, > so it's nothing new Yes already in Pio the drive reports its burst sizes. Yes as yet the drive does not report the total transfer length and not the residue. But ... > I doubt there's any drive > around that currently counts > how many extra words the host sends/takes > after the command is done. For data out, if the drive has data leftover in its fifo, odds aren't bad that it know how many bytes it has left. For data in, a compliant host cannot take extra "word"s beyond what the drive offers. Odds aren't bad that the drive offered only the "word"s it meant to offer. So then the only likely residue is the 1 pad byte unwillingly transferred along with the last byte of an odd count. > bridges ... that aren't allowed > to transfer the extra padding byte upstream on odd lengths, > 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. Aye painful. Worse than that. Before reading the count, the bridge can't commit the last X * 2 + 1 bytes, where X rises with burst rate. > 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. Yes, yuck. But as yet, the least awful alternative I've seen. The right time to fix this was back when Sff invented AtapiDma - in 1996 I think? Dunno how we all missed this all this time. (Me, I never owned any Dma implementation before now.) Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
