[t13] T10/04-262r1

Curtis Stevens curtis.stevens at wdc.com
Mon Aug 16 10:36:54 PDT 2004

* From the T10 Reflector (t10 at t10.org), posted by:
* "Curtis Stevens" <curtis.stevens at wdc.com>

	You make some really good points...

1. I have not really built in the ability to change PIO/DMA modes using
standard set features.  I will include a warning...
2. You generally have to follow the rules.  I have provided protocol #0 as
an out just for that reason.  However, I can put in a warning to make it
more clear.
3. I chose the list of protocols because I do not need to define them here.
The list is taken directly from ATA/ATAPI-7.  The developer of the
translator has an abundance of documentation on the protocols listed.  I do
not think there is anyway to future proof this.
4. I will add vendor specific commands to this list.  However, WD uses log
pages for transporting vendor specific commands.  Ergo, this is not a
limitation for WD drives.
5. I agree that DMA and UDMA are virtually the same.
6. I am including the DMA bit because some very simple devices will not
implement the protocol field.  DMA, Direction, and Length really give you
all the information you need for the vast majority of commands and makes for
smaller implementation in some environments.

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
Sent:	Friday, August 13, 2004 6:26 PM
To:	Curtis Stevens
Cc:	t10 at t10.org; Forum at t13.org
Subject:	Re: [t13] T10/04-262r1

* From the T10 Reflector (t10 at t10.org), posted by:
* Jeff Garzik <jgarzik at pobox.com>

Doc 04-262r1 gets my vote of approval.

Major comments:

* when a SET FEATURES - XFER MODE command is issued, any bridge / OS 
driver is -STRONGLY ADVISED- to perform implementation-specific actions 
necessary to accomodate the command [such as reprogramming controller 
PIO or DMA timings]

* perhaps mention somewhere that command protocol, if specified MUST 
[using RFC language] be correct with regards to the command opcode. 
i.e. it should be a spec violation for the application to specify a READ 
DMA opcode but a PIO-In protocol.  Behavior in that case is defined as 
undefined :)

Minor comments:

* I prefer my list of command protocols, because the list is more 
abstract and transport-independent.  More "future-proof."

* similarly, if one to pursue the idea of abstraction, it would be nice 
to have three bits:  host-reset, bus-reset, and device-reset.  rather 
than HWRST.

* (regarding command protocol) "Bridges that do not implement this field 
may not be able to execute queued commands."  I would add mention of 
similar limitation in execution of vendor-reserved commands

* why separate protocols for pio-{in,out} and udma-{in,out} when you 
have a separate bit for data direction?

* in practice DMA in/out and udma in/out are the same

* is the DMA bit needed any longer?

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

* 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