[t13] T10/04-262r0

Jeff Garzik jgarzik at pobox.com
Thu Aug 12 21:48:19 PDT 2004

* From the T10 Reflector (t10 at t10.org), posted by:
* Jeff Garzik <jgarzik at pobox.com>
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?


> 	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
> 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
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.



* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list