[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?
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
*
* 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