This message is from the T13 list server.
First, I am disappointed at the quality of the actual proposal (e03132) - the document is virtually impossible to read and understand. I did see the PPT overview document (e03131) so I think I can understand the requirements of the proposal. Second, the current proposal is making inappropriate changes. My proposal would look something like this... We need a general description of this feature in clause 4.x (of ATA/ATAPI-7). I'm not going to supply those one or two paragraphs here (lets get the technical part done first). I suggest the following implementation (the technical part)... When a device implements the DMADIR feature: A) ID data changes - 1) ID word 49 bit 8 shall be zero (this is the traditional DMA supported bit). 2) A bit in word 49 or 50 (50 is better) should be one to indicate that DMA is supported via the the DMADIR feature. 3) The contents of ID words 63 and 88 need to be moved to some new words (words that are currently reserved, that is words above word 128). The new words should have the same format and definition as words 63 and 88. These new words shall be zero when the DMADIR feature is not supported. No other ID word changes are required. This does not break old devices and old host software. This means that new software must look at the new bit in ID word 49 or 50 to see if the device supports DMA via the DMADIR feature and if so look at the copies of words 63 and 88 to determine the DMA modes supported and the current active mode. [This does bring up an interesting questions - if this feature is intended for use by SATA-to-PATA bridge chips then... since a SATA host doesn't care about PIO and DMA modes but the bridge chip needs to worry about PATA PIO and DMA modes, it seems the bridge needs to make sure the correct PIO and DMA modes are being used on the PATA interface. Why should the SATA host care about this? Doesn't this mean the bridge needs to understand the device ID data and issue the appropriate SET FEATURES commands to the PATA device? If the SATA host needs to worry about this how does the SATA host identify that there is a bridge chip in the interface? Isn't this all just a big mess?] B) In the PACKET command, if the device supports the DMADIR feature - Add the DMADIR bit to the Input Feature register. The description should say... * A device that does not support the DMADIR feature may abort a command if DMADIR is set to one. * A device that supports the DMADIR feature shall ignore the DMADIR bit if a command sets the DMA bit (Features register bit 0) to zero. * If the device supports the DMADIR feature and the DMA bit (Features bit 0) is one and if the command transfers data the device shall report a <TBD> error if the data transfer direction of the DMADIR bit does not match the data transfer direction of the command. No other change is required in the PACKET command description. There is no reason to modify the IO and CD bit description when this feature is implemented. Lets see if I have covered all the cases (a "new" device is an ATA/ATAPI-7 device): dev ID 49 ID ?? FR bit0 FR bit2 type bit 8 DMADIR DMA DMADIR result(s) ---- ----- ------ ------- ------- ---------- old x x x 1 may ABRT** old 0 0 0 0 OK (PIO cmd) old 0 0 1 0 may ABRT** old 1 0 0 0 OK (PIO cmd) old 1 0 1 0 OK (DMA cmd) new 0 0 0 x OK (PIO cmd) new 0 0 1 x shall ABRT new 1 0 0 x OK (PIO cmd) new 1 0 1 x OK (DMA cmd) new 0 1 0 x OK (PIO cmd) new 0 1 1 0/1 OK*(DMA cmd) new 1 1 x x illegal ID * - shall ABRT if DMADIR does not match command's data transfer direction. ** - the device may ABRT the command (invalid Features register) or the device may ignore the Features register and assume a PIO commandim.g Hale *** Hale Landis *** www.ata-atapi.com ***
