This message is from the T13 list server.
The is a reply to several of Pat's emails this morning. PLEASE NOTE: It includes, at the end, my suggestion for a proposal to fix Pat's problem. Comments are requested, especially from host adapter designers. Pat said: >With the change to Atapi Dma from Pio, we of T13 have precluded >Microsoft from properly supporting T10 over time. We of T13 have documented ATAPI DMA (except for one problem with the SERVICE command) exactly as described by SFF/INF-8020. There are ATAPI devices shipping that support DMA correctly and I have not heard anyone say they don't work with <OS name here>. >Sorry about that. I wasn't paying attention. Only recently did >burst rates above 17e+6 byte/s begin to matter to me. For ATA and ATAPI, SW DMA, MW DMA and U-DMA are all the same. There never was a Byte Count value associated with each DMA data burst like there is for each PIO DRQ data block. >Somebody somewhere at some time didn't copy that feature to Dma >from Pio. Pat, I think here is where you are getting confused. There is no need for this feature. I'll even go further and say there is no need for an ATAPI device in PIO to ever present a Byte Count value that is an odd number. We all now that the ATA interface can only transfer an even number of bytes. We all know that any odd BC value is allowed only for the last DRQ data block for the command. But above all, only the command (the ATA command or the ATAPI/SCSI CDB defines the number of bytes the command shall transfers). The ATAPI BC is a transport protocol thing, nothing more. DMA (ATA or ATAPI) don't need a BC because the transport protocol uses a different method to indicate DMA data burst size. >See the difference in the devices? The ByteCount from the first >device is 6, from the second device it is 5. The Dma trace shows >no ByteCount and no C/D I/O bits. So what? The ATAPI/SCSI CDB tells both the device and the host OS device driver stack how many bytes are being transferred. The host hardware or software must deal with the possiblity of a pad byte because of the design of the ATA interface. >T13 Pio lets the device tell the OS, T13 Dma does not. Sorry... Only the ATAPI/SCSI CDB tells the host and device how much data to transfer. >AtapiDma differs from AtapiPio by denying the device the >privilege of asking to copy an odd count of bytes. Only the ATAPI/SCSCI CDB tell the host and device how much data to transfer. >To make that residue accurate, the host & the device have to >negotiate a length of bytes to copy across the bus. >The "bus residue" is then the count of these "extra" "pad" >bytes. There is only one of these bytes possible. If it is present it is the last byte of the last PIO DRQ data burst or the last byte of the last DMA data burst. Only the ATAPI/SCSI CDB tell both the host and device if that byte is required on the ATA interface. >I'd say I'm asking how enhance AtapiDma to include a traditional >feature that forms a part of every other Scsi-over-whatever >protocol that actually just plain works, such as AtapiPio. Lets see your proposal. But let me make a try at it... Hale's proposal follows: Should Hale get a document number??? You want a Byte Count for each DMA data burst just as we have BC for PIO DRQ data blocks. This BC must be transmitted from the devcie to the host at some point in each DMA data burst. On the host side these BC values must be added up and made available to the host software. And lets assume that we are adding this feature to U-DMA because it is the only DMA we really want people using in the future (SW DMA has been obsolete for years, and not supported by ATA hosts for years; MW DMA probably should be made obsolete sometime soon). OK, how about this? For U-DMA we define a scheme where the CRC is replaced by this BC value? Or do we need to define an entirely new DMA protocol (how about Enhanced Ultra DMA?) that has not only the CRC but the BC value? *** Hale Landis *** www.ata-atapi.com ***
