[t13] T10/04-262r1

Curtis Stevens curtis.stevens at wdc.com
Tue Aug 17 13:15:42 PDT 2004


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

	I floated the idea of doing a transport for vendor specific
commands, but was told by several people that a more generic interface was
preferable.  There is a technical report (DT1701-SCT) on the T13 site that
documents a method for transporting vendor specific commands using standard
ATA commands.

1. At this point, I am attempting to document a pass through for a "blind"
bridge.  This means that the bridge should not be looking at or parsing the
command code.  This makes for a much simpler pass through mechanism.  In
keeping with the blind concept, the bridge itself owns the ATA host
configuration and knows what speeds have been setup for the various modes of
transfer.  The bridge needs to know if the command code causes a PIO or DMA
transfer, the direction, and the length of the transfer.  With this
information a simple bridge can execute almost all of the commands.  This
was my original proposal...  There were people that felt queuing could be
exercised if a protocol field was added.  So, added 1 field to allow for
greater capability in the future to support queuing.  It is only coincidence
that this also helps, in some cases, for vendor specific commands.  It will
NOT be helping WD for their vendor specific commands.  My intention in
making this proposal is to document a standard method for performing
manufacturing and technical support on ATA devices that are bridged to SCSI.
It is not my intention to use this for the "heavy lifting" or normal ATA
full-time operation.
2. Parallel ATA is still the most common device that is bridged, it uses
USB.  My bridge will not be parsing the protocol field because I do not need
queuing or special vendor specific support, but I did not want to prevent
others from doing so.  Since this field is optional, the host can just put
zero there and not use it.  The fields documented can easily be mapped to
PATA or SATA.
3. The *.EN are used for standard ATA commands.  Many of the commands have
marked certain registers as reserved.  Using the *.EN bits allows the host
to inform the bridge that it does not need to store a specific register.
This keeps the bridge from having to maintain a list of commands and their
attributes.
4. The DMA field is important for both SATA and PATA.  In the case of PATA
you either transfer by setting up a DMA controller or reading from a port.
In the case of SATA it informs the translator that it should be accepting
PIO SETUP or DMA SETUP FISes.
5. Since the host is passing this in a CDB and the bridge is not looking at
the command, the Multiple.Count field is the only way that the bridge can
know what the DRQ block size is.  The host configures the DRQ block size by
issuing a SET MULTIPLE MODE command to the ATA device.

I hope this helps.


------------------------------------------------
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: 	Marushak, Nathan [mailto:nathan.marushak at intel.com] 
Sent:	Tuesday, August 17, 2004 11:56 AM
To:	Curtis Stevens; t10 at t10.org; Forum at t13.org
Subject:	RE: [t13] T10/04-262r1

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.

Thanks,
Nate

-----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.


Jeff

	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
Garzik
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