[t13] T10/04-262r0

Curtis Stevens curtis.stevens at wdc.com
Thu Aug 12 17:17:52 PDT 2004


This message is from the T13 list server.


Jeff

	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

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
 
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at wdc.com

 -----Original Message-----
From: 	owner-t10 at t10.org [mailto:owner-t10 at t10.org]  On Behalf Of Jeff
Garzik
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.
> 
> 
> Jeff
> 
> 	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
from
> the transport.  The transport has direction, transfer size, and other
useful
> 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 
missing:
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.

	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