UAS Query

Mark Overby MOverby at nvidia.com
Mon Mar 23 09:25:15 PDT 2009


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0903231_f.htm">HTML-formatted message</a>

I wouldn't phrase it as replacing a SAS driver with a UAS driver. It's more
along the lines of having a (in Linux terms) SCSI LLD talking across the USB
bus.
On 3/19/09 7:18 AM, "Curtis Stevens" <curtis.stevens at wdc.com> wrote:
* From the T10 Reflector (t10 at t10.org), posted by:
* "Curtis Stevens" <curtis.stevens at wdc.com>
*
USB requires that each phase of the command be configured separately.  This
is the case for both BOT and UAS.  BOT requires that the Bulk-in pipe be
configured for both read commands and status returns separately from the
Bulk-out pipe which is used for commands and write data.  At the lowest
levels, all these operations need to be configured.  The place where this
configuration is comprehended will vary by driver stack.  UAS is architected
to take advantage of USB-3 controllers which are capable of holding multiple
requests on the host side.  This removes the single threaded aspect which is
present in BOT.
Actually, there are more than the 3 cases, depending on what you are doing
you may need bi directional commands.  I am not sure about your
implementation, but you may also need something separate for task management
as well.
Typically, a storage driver receives a request that is translated into a
physical command at some point.  The command may be created within the
higher level driver, or in a layer below.  Whatever creates the commands
usually provides additional information to the lower layers including
length, direction and a buffer pointer.  The UAS driver takes this
information and uses it to create transactions on the USB-2 and USB-3 buses.
If you are taking the approach of modifying a BOT driver into a UAS driver
you may want to rethink your strategy.	UAS is architected to allow you to
replace the lowest level SAS driver with a UAS driver.
-------------------------------------------------
Curtis E. Stevens
Sr. Staff  Engr - Standards & Features Technology
20511 Lake Forest Drive #A 113-F
Lake Forest, California 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 Madhukar
Sent: Thursday, March 19, 2009 5:24 AM
To: t10 at t10.org
Subject: UAS Query
* From the T10 Reflector (t10 at t10.org), posted by:
* Madhukar <madhukar.gubba at gmail.com>
*
Hi All,
I'm a linux device driver developer. I was looking at UAS
specification document. I have basic question from a driver developer
perspective. Pardon me if this is not the right question that needs to
be asked at this place.
The command sequence diagram for non-data, data-in or data-out has a
different sequence of communication. Does the driver developer need to
determine type of SCSI command and then handle appropriate command
sequece?
if <read> SCSI command
{
	handle data-in command sequece
}
if <write> SCSI command
{
	handle data-out command sequece
}
anything else
{
	handle non-data command sequence
}
The existing BOT protocol does not require to know the type of SCSI
command, it just fills command block wrapper and gets respose in
command status wrapper.
Thanks in Advance.
Regards,
Madhukar
*
* 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
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------



More information about the T10 mailing list