This message is from the T13 list server.
I'm back... This is a proposal to fix the DMA host adapter problem we were discussing with Pat a week ago. While this is not a complete solution to the problem a host has determining how much data a DMA data transfer attempted to transfer, it does provide a mimimum level of information for a host and it does provide enough information to provide a host with a sense of data integrity for DMA transfers. This proposal does not require a counter that counts the number of bytes moved by a DMA transfer. Instead it provides two bits of state information that will allow a host to determine how much of the PRD list was actually used, therefore how much of the host I/O bufer was used. The bits are both set to 0 when the DMA engine is started by the host. The host software should not use the value of the bits until the DMA engine stops. These two bits, I will call them X and Y here, have four states: XY=00 - The Y and X bits are set to 0 when the DMA engine is started. XY=01 - The Y bit remains 0 and the X bit is set to 1 when a) for a DMA read command when the first word of data is received on the ATA interface, and b) for a DMA write command when the first word of data is send on the ATA interface. XY=10 - The Y bit is set to 1 and the X bit is set to 0 when a) for a DMA read command when the last word (last word of the last PRD list entry) of the host I/O buffer is stored, and b) for a DMA write command when the last word (last word for the last PRD list entry) is sent on the ATA interface. XY=11 - The Y bit remains 1 and the X bit is set to 1 for a DMA read command when the host receives one or more extra words on the ATA interface (more words than the PRD list describes). This state does not exist for a DMA write command because the DMA engine will stop at the end of the PRD list (when XY-10) but the device will hang with DMARQ asserted. Valid sequences for Y and X are: 00 - No data was transferred. 00, 01 - Some data was transferred but not all the data. 00, 01, 10 - Exactly the amount of data described by the PRD list was transferred. 00, 01, 10, 11 - For a DMA read command more data was received from the device than could be stored in system memory (the end of the PRD list was reached but more data was received by the host). This is not prefect but assuming a properly programmed host side device driver that builds a PRD list that transfers exactly the correct amount of data (the *ONLY* way a host should be implemented if you expect your OS to have data integrity) then these bits can be used by the device driver to determine how much data was transferred. Note that the PRD list should include any pad byte that might be required. So here is a way to vastly improve the data integrity of ATA DMA host adapters and solve the problem the Pat was talking about (because what Pat is talking about is not an ATA/ATAPI interface or ATA/ATAPI device problem) and it does not require an ATA DMA host adapter to actually count the data bytes/words during a DMA data transfer. I would like to see this added to the ATA host adapter proposal (as a mandatory thing). Without something like this (or a byte/word counter) using DMA on PCI bus ATA host adapters is risky. I have been complaining about this for years and I do not understand why more people do not understand the DMA data integrity problem that exists in PCI bus ATA host adapters (as defined by Intel). Note that this should word even for ATAPI (or future ATA) devices that are allowed to "release" in the middle of the DMA data transfer for a DMA "queued" command. *** Hale Landis *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org.
