curtis.stevens at wdc.com
Thu Aug 12 17:17:52 PDT 2004
This message is from the T13 list server.
I have been looking at the protocol definitions and I see the
1. Hard Reset
3. Bus Idle
5. PIO Data-In
6. PIO Data-Out
9. DMA Queued
10. Device Diagnostic
11. DEVICE RESET
12. UDMA Data In
13. UDMA Data Out
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?
Curtis E. Stevens
20511 Lake Forest Dr. #C 214-D
Lake Forest, Ca. 92630
E-Mail: Curtis.Stevens at wdc.com
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Jeff
Sent: Thursday, August 12, 2004 2:55 PM
To: Curtis Stevens
Cc: t10 at t10.org; Forum at t13.org
Subject: Re: [t13] T10/04-262r0
* From the T10 Reflector (t10 at t10.org), posted by:
* Jeff Garzik <jgarzik at pobox.com>
Curtis Stevens wrote:
> This message is from the T13 list server.
> I think you were actually looking at T10/04-262r0...
> 1. I don't think this addresses queuing very well. In the scope I have
> excluded queing from the support. That does not mean that it can not be
> made to work...
> 2. I agree with you. However, I do not think the CDB can be separated
> the transport. The transport has direction, transfer size, and other
> bits of information. I included the DMA bit because an ATA host need to
> know to use DMA or PIO to transfer the data. I have also included the DRQ
> block size for PIO transfers. I think that gives you all the information
> you need to do the transfer. That being said, if it would make things
> easier to use, I can remove the DMA bit in favor of a field that specs
> protocol. What do others think?
Fundamentally, the command protocol is tied to the command opcode being
executed, not the transport.
The transport merely implements the command protocol. This fact has
remained true from the oldest PATA controllers to the newest SATA
controllers (ones not yet on the market).
Without an explicit command protocol field, the following information is
PIO versus PIO-Mult versus ATAPI PIO
DMA versus TCQ DMA versus NCQ DMA versus ATAPI DMA
A single byte, command protocol, can provide all this information and
more. With command protocol byte, your CDB is "future proof": you
don't need to specify additional bit flags for DMA, PIO Mult, TCQ, NCQ,
etc. A command protocol byte automatically takes queueing into account.
[personal note: any design that doesn't take TCQ/NCQ into account is,
IMO, automatically outdated. Ask your drive guys ;-)]
In the implementation of the low-level driver, all this information is
required, and all this information is independent of transport. For
known ATA commands, this missing information can be provided by a lookup
table. For unknown (vendor reserved) commands, this information must be
specified by the client app _somewhere_, since the low-level driver
cannot know it.
* 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