This message is from the T13 list server.
On Fri, 25 Jan 2002 13:56:02 -0500, Mark Sawyer wrote: >That said, I am working at the device driver level, a lower layer >sufficiently removed from the upper "host" layer such that I am not privy to >the details of the underlying device filesystem or media format. Also, in >my particular situation, the "host" layer does not request I/O transfers in >bytes, it requests them in "blocks" ... hence my dilemma. In most OS device driver designs, the lowest level device driver (Microsoft calls this the mini-port driver) needs to have access to lots of data but most certainly it needs the "command block" to send to the device and it needs to have enough information about the host side I/O buffer to correctly transfer the data in PIO mode or to program the host side DMA engine. I think we must assume the lowest level driver will receive some indication of the number of bytes that will be transferred or at least the size of the I/O buffer because this driver should not attempt to fetch or store data outside the bounds of the I/O buffer! >In my case, the simplest solution, in my not so humble opinion, would be for >the upper host layer to pass the anticipated bytecount to the lower layer. >Will they? I don't think it likely. Why? I'd rather not go there ;-( Lets look at each possible data transfer case... ===begin * PIO data in (a read) - You must use the Byte Count value for each DRQ data block to transfer the data for each DRQ data block. If the total amount of data transferred by the device fits into the host side buffer (the normal case) then there is no problem. If the total amount of data does not fit into the host side I/O buffer then you must either: a) continue to transfer data but discard the data than will not fit into the host side I/O buffer, OR b) declare an error condition and reset the device (to halt the command). ['b' is the better choice because some ATAPI device have the strange habit of getting into an infinite data transfer loop sending DRQ block after DRQ block sending data forever.] * PIO data out (a write) - You must use the Byte Count value for each DRQ data block to transfer the data for each DRQ data block. If the device attempts to transfer more data than you have in the host side I/O buffer you must declare an error condition and reset the device. ** In the cases of PIO data in and PIO data out, the sum of all Byte Count values for all DRQ data blocks is the amount of data transferred by the device but the last byte transferred may have been a pad byte not included in this count. * DMA data in (a read) - You must know how to program the host side DMA engine. That normally includes knowing the exact number of bytes to transfer or the maximum number of bytes that can be transferred (the total size of the host side I/O buffer). If the host side DMA engine is programmed to transfer too few bytes then the device will have waiting to transfer more data to the host and the host will need to reset it in order to continue. * DMA data out (a write) - You must know how to program the host side DMA engine. That normally includes knowing the exact number of bytes to transfer or the maximum number of bytes that can be transferred (the total size of the host side I/O buffer). If the host side DMA engine is programmed to transfer too few bytes then the device will hang waiting for more data from the host and the host will need to reset it to continue. ** For PIO data out and DMA data out the host side must be aware that a pad byte may be required at the end of the transfer. The big problem here is that if the higher level software does not provide this byte then the low level driver may need to do all kinds of extra processing in order to provide the data byte... for example, think about things like "double buffering" the data in the low level I/O driver. ** For DMA data in and DMA data out it would be nice if the host side DMA engine returned the total number of bytes that were transferred. On old x86 systems using the ISA bus DMA engines we had that facility. On newer x86 PCI bus systems this very important information is not provided by the DMA engine. PCI Bus Mastering DMA ATA controllers are very stupid should be considered just barely adequate for use with ATA devices and should not be used on ATAPI devices on commands that can transfer a variable amount of data. ===end Now lets summarize this... For PIO data in and DMA data in (read commands) the host side must be prepared to receive all the data the device sends. This means the host side must provide a I/O buffer that will hold all that data. The host side buffer could provide a larger data buffer but the host should understand that extra buffer space does not receive data from the device. Mark said (above) his driver only knows the "block count". But it needs more than that... At the minimum it needs to know the size of the host side I/O buffer. The device might not transfer enough data to use the entire buffer and we must assume that this is considered OK. But my question would be: What is the "block count" for a Request Sense or Inquiry command and what is the associated "block size" for these commands? For PIO data out and DMA data out (write commands) the host side must be prepared to send all the data the device requests. This means the host side must provide a I/O buffer containing all that data. The host side could provide a larger data buffer but the host should understand the extra data will never be transferred to the device. Mark said (above) his driver only knows the "block count". But it needs more than that... At the minimum it needs to know the size of the host side I/O buffer. The device might not transfer all that data but we must assume that this is considered OK. But my question would be: What is the "block count" for a Mode Select command and what is the associated "block size" for this command? Finally... I think Mark's problems are not that difficult but my advice is: get that drive driver interface fixed so that you know not only the host side I/O buffer size but also the expected amount of data to be transferred. At the minimum Mark's driver needs to know the "block size" to be used with the current command (so that you can do a Mode Sense or Mode Select command with a fake block count of one and a block size of whatever is required for the mode pages that will be transferred). *** Hale Landis *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
