[t13] T10/04-262r1

Marushak, Nathan nathan.marushak at intel.com
Tue Aug 17 11:56:09 PDT 2004

* From the T10 Reflector (t10 at t10.org), posted by:
* "Marushak, Nathan" <nathan.marushak at intel.com>
I have been a little troubled by the idea of making accommodations for
vendor unique commands to the proposed standard ATA pass-through
mechanism.  Specifically, I want to avoid forcing the user (driver) of
SATL from having to worry about determining protocol type.  Consider a
situation where a customer wants to use the pass-through mechanism for
performing normal reads and writes (a.k.a. fast path operation).  It
slows down their implementation to have to parse and specify data
protocol each time.

I spoke with Bob Sheffield and he indicated a potential alternative that
warrants consideration in my mind.  Consider creating an ATA
pass-through mechanism for standard commands and a separate ATA
pass-through for vendor unique commands.

Other comments follow:

Extend field - Does it make sense to simply follow the SATA mechanism
which always transfers a packet that includes all registers (including
extended).  Doing so maps well to SATA and removes the need for the
"Extend" bit and 2 separate tables.  This would also remove the need for
the SRST field as well since there would be a control register
containing the SRST bit.

Multiple.Count field - Is this field really necessary?  Isn't the
host/driver supposed to configure this prior to issuing any PIO
requests?  As such, is it wrong to have the host/driver and SATL
remember the value?  In SATA, the target specifies the amount to be
transferred for each PIO segment by setting it in the PIO Setup FIS.

*.En, DMA fields - Are these bits required for vendor unique commands?
I'm trying to determine the need for these fields when performing
standard pass-through of well defined standard ATA commands.  For
standard defined ATA commands each field has a well-defined set of
values or is not applicable.  For the not applicable case the device
will worry about whether the field has a relevant value in it or not.


-----Original Message-----
From: owner-forum at t13.org [mailto:owner-forum at t13.org] On Behalf Of
Curtis Stevens
Sent: Monday, August 16, 2004 10:37 AM
To: t10 at t10.org; Forum at t13.org
Subject: RE: [t13] T10/04-262r1

This message is from the T13 list server.


	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
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
The list is taken directly from ATA/ATAPI-7.  The developer of the
translator has an abundance of documentation on the protocols listed.  I
not think there is anyway to future proof this.
4. I will add vendor specific commands to this list.  However, WD uses
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
all the information you need for the vast majority of commands and makes
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