UAS data-in sent to status synchronization comment/issue

John Garney jig at mcci.com
Tue Feb 2 07:46:33 PST 2010


* From the T10 Reflector (t10 at t10.org), posted by:
* John Garney <jig at mcci.com>
*
Curtis,
UAS requires that the status ERDY for SuperSpeed operation is not  
issued for the status endpoint until after the last transaction  for  
the Data-in pipe (for a read or bi-directional command) has been  
acknowledged by the host.  This synchronization requirement requires  
that USB3 device silicon indicate to the device firmware/logic the  
receipt of the host ACK for the data-in pipe.
Several very popular device IP cores and commercial USB 2.0 silicon  
all lack the ability to let you quickly and conveniently know that  
data is really transferred to the host on an IN pipe.  You get an  
interrupt when data has been loaded into the FIFO, and the core takes  
care of moving to the host.
These cores are used in things like cell phones, media players, and  
other devices that are multi-function devices, presenting mass storage	
plus other functions to the host PC as composite devices.   Virtually  
every cell phone shipped today uses one of these general purpose  
cores, and offers mass storage; so this is not a trivial or low-volume	
use case.
This lack of precision for data transfer has not been a problem in  
practice until now (for UAS) -- so the new USB3 cores will not require	
this feature, and this will force use of BOT instead of UAS.
Since the reporting of the completion events of transfer requests of  
data and status endpoints to the UAS driver can occur in any order in  
any case (due to xHCI interrupt reporting and OS scheduling  
variations), this seems like an unnecessary requirement for the  
transactions on the SuperSpeed bus.
Note that this will also be an issue for USB2 UAS operation.  The ERDY	
is not present, but the device shall not respond with the STATUS_IU on	
the status pipe until after the host ACK on the last data-in  
transaction.  And lots of current silicon doesn't have support for  
that transition.
Further, in USB2, the data-in ACK can be smashed.  If the ACK is  
smashed, the device won't respond with the STATUS_IU; as there is no  
normal retry on ACK smash in USB2.  This smash case can be recovered  
if there is a subsequent data-in transaction (as it will be detected  
by data toggle state).	However, since the next transfer (for the next	
command) isn't allowed until the status IU is returned, the device  
will just wait.  Presumably, the host (driver) will timeout the  
command; but this could turn a successful command into an error case  
with a long delay.
/jig/
*
* 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