This message is from the T13 list server.
Curtis Stevens wrote:
The READ DMA QUEUED EXT documents that it is part of the DMA Queued protocol, but this gives no concept of direction. Are you saying that I should allocate 4 bits for protocol, list the available protocols and provide a bit for direction?
Yes.
I have been looking at the protocol definitions and I see the following:
1. Hard Reset 2. SRST 3. Bus Idle 4. Non-data 5. PIO Data-In 6. PIO Data-Out 7. DMA 8. Packet 9. DMA Queued 10. Device Diagnostic 11. DEVICE RESET 12. UDMA Data In 13. UDMA Data Out
In my code, and other software implementations I've seen, the list winds up being:
1. Hard Reset
2. SRST
3. device reset
4. device diagnostic
5. packet
6. non-data
7. pio-{in,out}
8. pio-mult-{in,out}
9. dma-{in,out}
10. dma-queued-{in,out}
11. fpdma-queued-{in,out} [a.k.a. NCQ]Why is my list different? Because it is based on a slightly more abstract, transport-independent concept. The command protocol can also be termed a "command class", such that a
{ command opcode, command class }pair is guaranteed to uniquely identify to the OS driver [and possibly host controller] how to execute an ATA command. This list is based on the implementation details required by the OS driver [and possibly host controller], _not_ specific details of the underlying transport.
This is the reason why, e.g., there is no udma-{in,out}. "MWDMA" versus "UDMA" is a transport detail. Also note that Overlapped feature set does not require an entry the list above.
Regards,
Jeff
