This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ] Jim M: Thanks again for the recent burst of email. I think we now agree that an actual Atapi host rude enough to ask to copy too many bytes may provoke a "bus residue" as large as X * 2 bytes, where X rises with burst rate. To be sure we agree, I offer below a paraphrase to show you what I heard ... carefully avoiding all mention of the word "residue". Please reply again to confirm/ deny/ correct my understanding. > Subject: ... to what can we all agree > Date: Monday - April 15, 2002 10:50 PM When the host & the device do agree over how many bytes to copy which way, life is delightfully simple. But let us suppose an Atapi host rudely does ask to copy more bytes, at a time when the Atapi device & host do agree over which way to copy bytes. When copying data via Pio, the device can ask to stop the copy at any "byte" boundary. When copying data via SwDma, the device can ask to stop the copy at any "word" boundary. When copying data via MwDma, T13 allows the device asking to stop the copy to be slow. This means our rude host ends up copying X extra "word"s, where X may be 0 or 1. In practice, people don't make many devices this slow. When copying data In via UDma, the device can ask to stop the copy at any "word" boundary. Here UDma is as precise as SwDma and MwDma in practice, and better than MwDma on paper. When copying data Out via UDma, the device the device can ask to stop the copy at any "word" boundary, but then the host may send another X "word"s. T13 requires the device to ignore these "word"s. Have I understood you correctly? If no, please let's fix that first. If yes, then you understand one part of my proposal: I want us (T13) to give the device a way t report X for MwDma and UDma. Thanks in advance, Pat LaVarre http://members.aol.com/plscsi/cdbcomplete.html From: McGrath, Jim Subject: RE: [t13] on residue - to what can we all agree [ Here I quote Jim without the ... parts to try and focus first on where we agree. ] Pat, ... the host software must crack the CDB ... You contend that the host software can avoid that. Yes and no. It can only avoid that if it relies on the device to crack the CDB (afterall, someone has to do it). And then certain other behaviors you have cited as undesirable MUST follow. For instance, on writes the host does not know how to program the host DMA controller. It has a buffer, and perhaps a length, but has no idea what is in the buffer. So it will just program the host hardware to start at the buffer starting address and to transfer everything in the buffer. The device did crack the CDB, so it knows that only 80% of the buffer (for example) has valid command data (the mismatch is due to the fact that the buffer was allocated in easy multiples, like powers of 2 bytes, in order to avoid memory fragmentation). So the host will transfer away. After the device receives the 80% it is due, it will try and halt the DMA transfer. But at this point the host will still be blasting away, so the up to 3 extra words that the device can receive may be received (and ignored by the device as per the ATA standard). Looking at reads is instructive. In this case you would also expect that a host that does not crack the CDB would try to overflow (i.e. overread) bytes into the host buffer. Assume that the device is cracking the CDB. In SW or MW DMA the host has to drive the DMA process, so it has to figure out how many bytes to request. In practice it would just start a DMA burst, and continue with DMA bursts until once again the device refuses to participate in a DMA burst and instead signals the end of the command. With a fast DMA, the host could overread a word on the last DMA burst before it wouldsee the device trying to terminate the command. But this can never happen with UDMA. Here it is the device that determines the number of words to transfer - it pushes words rather than having the host pull them. When the device runs out of words, it just stops sending them - no overflow can possibly occur on the ATA bus. ...
