[t13] T10/04-262r1

Marushak, Nathan nathan.marushak at intel.com
Fri Aug 20 15:24:08 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Marushak, Nathan" <nathan.marushak at intel.com>
*
Curtis has enlightened me as to the specific issues he is attempting to
address.  As a result, I rescind my previous questions/issues. 

-----Original Message-----
From: Curtis Stevens [mailto:curtis.stevens at wdc.com] 
Sent: Friday, August 20, 2004 1:53 PM
To: Marushak, Nathan; t10 at t10.org; Forum at t13.org
Subject: RE: [t13] T10/04-262r1

Nate

	The place where we are not communicating is that you are looking
for
the bridge to check the command code.  I do not want the bridge to ever
have
to look at the command code.  Can you send me your contact info, I think
a
quick chat on the phone can bring us together...


------------------------------------------------
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:	Friday, August 20, 2004 1:48 PM
To:	Curtis Stevens; t10 at t10.org; Forum at t13.org
Subject:	RE: [t13] T10/04-262r1

Curtis,

Thanks for your time in addressing my questions.  Unfortunately I'm
still not on the same page.  I have a few comments below inline
(prefixed with NATE), but I'm starting to feel that this may need to be
something we work through at the F2F.  Maybe my parser isn't working
very well :-)

I think my problem is I don't have a good understanding for your bridge
issues.  I'm looking at the problems from a different perspective.

Nate

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

This message is from the T13 list server.


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.

NATE: Yes they can be mapped, but this would force a mapping to occur
instead of simply allowing a straight pass-through.

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.

NATE: The validity of the fields can be determined by parsing the
command field.  In my mind, we seem to be forcing the passthrough
mechanism to do more translation than what is necessary for translating
some SCSI commands.

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.

NATE: Again my thought is the translator can get this information from
parsing the command field.  In essence having this field forces the
driver above the translator to have to parse the command.

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.

NATE: Why can't the translator simply remember the MULTIPLE MODE setting
that was done at device configuration time?

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