[t13] T10/04-262r0

Marushak, Nathan nathan.marushak at intel.com
Thu Aug 12 14:19:45 PDT 2004

* From the T10 Reflector (t10 at t10.org), posted by:
* "Marushak, Nathan" <nathan.marushak at intel.com>

I'm not sure I follow the need to specify the protocol.  The assumption
is we are passing through an ATA command to an ATA controller.  As such,
the "cumbersome (and unneeded) table or switch statement" has always
gone with the ATA controller.  Somebody has to perform the lookup to go
|from command type to the sequence type (data protocol), whether it be at
the highest level, lowest level, or somewhere in between.

As far as vendor unique commands...good question.  ATA Controllers have
to understand that the command being passed to them is vendor unique.
Understanding the command is vendor unique, then the controller won't
make any assumptions about subsequent packets.  Basically it will wait
until it receives signals or FISes back from the target before
understanding what the data protocol might be or what the next step is.
I believe this is true in all cases.

Suffice to say, I don't believe the existing ATA controllers on the
market require knowledge of each and every vendor unique command for
each and every target on the market, yet they do still allow for vendor
unique commands.

To summarize, I don't see the need to specify a data protocol since
there currently is no need to specify data protocol in a SATA Register


-----Original Message-----
From: owner-forum at t13.org [mailto:owner-forum at t13.org] On Behalf Of
Curtis Stevens
Sent: Thursday, August 12, 2004 1:43 PM
To: t10 at t10.org; Forum at t13.org
Subject: [t13] T10/04-262r0

This message is from the T13 list server.


	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
the transport.  The transport has direction, transfer size, and other
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
block size for PIO transfers.  I think that gives you all the
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?

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: 	Jeff Garzik [mailto:jgarzik at pobox.com] 
Sent:	Wednesday, August 11, 2004 7:20 PM
To:	Curtis Stevens
Cc:	Sheffield, Robert L; t10 at t10.org; Forum at t13.org
Subject:	Re: [t13] SAT: Reminder - Teleconference Thur 8/12 9:00

Curtis Stevens wrote:
>             Just a heads up, I posted a proposal (04-260.PDF) for 
> documenting how a SCSI command maps to an ATA command.

This is fantastic.  A standard method of ATA passthru is the last piece 
of the puzzle, WRT SCSI<->ATA translation, that Linux needed.  Thank

One problem, which appears to be easily correctable:

Any ATA passthru method must specify the command protocol:  DMA-In, 
DMA-Out, TCQ DMA-In, TCQ DMA-Out, PIO-In, PIO-Out, PIO-In-Mult, etc.


1) For standard ATA commands, a cumbersome (and unneeded) lookup table 
or C 'switch' statement is required to obtain the command protocol.

2) The low-level ATA driver has no idea how to execute a vendor-reserved

ATA command without the command protocol.

My suggestion is to used the 'Reserved' byte for this data field.

The current Linux implementation of the "taskfile ioctl" (a.k.a. ATA 
passthru) includes the command protocol field.


* 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