On 19 May 2016 at 09:08, Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> Paul Zimmerman <pauldzim@xxxxxxxxx> writes:
>> Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> writes:
>>
>>> If we're going to issue a Update Transfer command,
>>> let's clear LST bit from previous TRB. This will let
>>> us continue processing TRBs and convert previous IRQ
>>> into XferInProgress, instead of XferComplete.
>>>
>>> Signed-off-by: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx>
>>> ---
>>> drivers/usb/dwc3/gadget.c | 32 +++++++++++++++++++++++---------
>>> 1 file changed, 23 insertions(+), 9 deletions(-)
>>
>> < snip >
>>
>>> + /*
>>> + * When trying to issue Update Transfer, we can remove LST bit from
>>> + * previous TRB and avoid a XferComplete
>>> + */
>>> + if (!starting) {
>>> + trb = &dep->trb_pool[dep->trb_enqueue - 1];
>>> + if (trb->ctrl & DWC3_TRB_CTRL_HWO)
>>> + trb->ctrl &= ~DWC3_TRB_CTRL_LST;
>>
>> Hi Felipe,
>>
>> This violates the DWC USB3 programming model. Once the HWO bit has been set
>> and the transfer started, the host is not allowed to modify any of the
>> fields in the TRB until the controller clears the HWO bit, or the transfer
>> completes or is halted.
>
With this patch and rndis interface and highspeed I have (tested using iperf):
275Mbps for TCP for both directions (305Mbps for UDP).
Without patch:
145Mbps for TCP
This is quite interesting, while I understand we violate programming
model here, but still have correct TCP traffic (also during MTP tests
didn't hit any issue)/
And the improvement is also nice. Maybe HW should add something like
APPEND_TRB which will set/clear this flag
correctly in the HW, while HW know if this is already safe.
This mean we still can improve dwc3 driver and get similar TP we have
with this "wrong" patch.
BR
Janusz
> oh that's right. Just found it on section 8.2.3.2. I'll drop this patch
> from the queue. Thanks for the note :-)
>
> Hope you're doing ok, Paul
>
> cheers
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
