usb: dwc3: gadget: Support Multi-Stream Transfer

Synopsys introduced a new enhancement to DWC_usb32 called Multi-Stream
Transfer (MST) to improve bulk streams performance for SuperSpeed and
SuperSpeed Plus. This enhancement allows the controller to look ahead
and process multiple bulk streams.

Previously, to initiate a bulk stream transfer, the driver has to issue
Start Transfer command and wait for the stream to complete before
initiating a new stream. As a result, the controller does not process
TRBs beyond a single stream. With the enhancement, as long as there are
new requests, the dwc3 driver can keep preparing new TRBs and the
controller can keep caching and processing them without waiting for the
transfer completion.

The programming flow is similar to regular bulk endpoint with a few
additional rules:

1) Chained TRBs of the same stream must have a matching stream ID
2) The last TRB of a stream must have CHN=0
3) All the TRBs with LST=0 must have CSP=1

Depends on the application and usage, internal tests show significant
performance improvement in UASP transfers with this enhancement.

Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
---
 drivers/usb/dwc3/core.h   |  9 +++++++++
 drivers/usb/dwc3/gadget.c | 26 +++++++++++++++++++++-----
 2 files changed, 30 insertions(+), 5 deletions(-)


base-commit: 4d012040161cba054208555300d9fdf2b8925c34

Hi Felipe,

Felipe Balbi wrote:
> 
> Hi Thinh,
> 
> Thinh Nguyen <Thinh.Nguyen@synopsys.com> writes:
>> Synopsys introduced a new enhancement to DWC_usb32 called Multi-Stream
>> Transfer (MST) to improve bulk streams performance for SuperSpeed and
>> SuperSpeed Plus. This enhancement allows the controller to look ahead
>> and process multiple bulk streams.
> 
> Finally!! This is a great improvement to the core :-)
> 
>> Previously, to initiate a bulk stream transfer, the driver has to issue
>> Start Transfer command and wait for the stream to complete before
>> initiating a new stream. As a result, the controller does not process
>> TRBs beyond a single stream. With the enhancement, as long as there are
>> new requests, the dwc3 driver can keep preparing new TRBs and the
>> controller can keep caching and processing them without waiting for the
>> transfer completion.
>>
>> The programming flow is similar to regular bulk endpoint with a few
>> additional rules:
>>
>> 1) Chained TRBs of the same stream must have a matching stream ID
>> 2) The last TRB of a stream must have CHN=0
>> 3) All the TRBs with LST=0 must have CSP=1
>>
>> Depends on the application and usage, internal tests show significant
>> performance improvement in UASP transfers with this enhancement.
> 
> Does this mean that we can now issue Start Transfer for each of the
> streams on the same endpoint? Should we start having per-stream TRBs,
> then? Maybe we don't need a full 256 TRBs for each stream, perhaps 16 to
> 32 TRBs for each stream ought to be enough?
> 

Sorry, I may not be clear in the description. Just like previously,
before we can issue a Start Transfer command, we need to make sure that
the endpoint transfer is completed or ended first. That hasn't changed.
However, previously, while the endpoint is started, all the TRBs need to
be of the same stream id.

The enhancement here allows the endpoint to remain "started" with
multiple streams of different IDs. The driver can add new streams/TRBs
with Update Transfer command.

MST is mainly for device initiated stream. We don't maintain multiple
TRB rings (one of for each stream) as xHCI driver for each active
stream. For device initiated stream, the device will have control of the
stream/transfer order. The order will be the order of the stream
requests queued by the function driver.

The dwc3 driver can indicate the last TRB of a stream ID with CHN=0.
This will tell the controller that it needs to switch/initiate stream on
the next TRB's stream ID.

In short, we will still keep the 256-TRB ring per endpoint. To keep the
driver behavior/implementation simple and consistent with regular bulk,
we will only need to issue Start Transfer at the beginning and continue
to prepare new TRBs from different streams using the same TRB ring. We
just need to follow the rules noted in the commit message.

BR,
Thinh