Hi Felipe,
On 1/21/2019 4:15 AM, Felipe Balbi wrote:
> Hi
>
> Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> writes:
>> Hi,
>>
>> Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> writes:
>>> Hi again,
>>>
>>> Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> writes:
>>>
>>> <snip>
>>>
>>>> Try to dequeue a request that was already completed. Odd. Why are we
>>>> missing a call to giveback??
>>> Got a little more information:
>>>
>>> file-storage-3982 [006] d... 131.010663: dwc3_ep_queue: ep1in: req 00000000eccaa10f length 0/16384 zsI ==> -115
>>> file-storage-3982 [006] d... 131.010667: dwc3_prepare_trb: ep1in: trb 000000002ab8a1f9 buf 00000000bde24000 size 16384 ctrl 00000811 (Hlcs:sC:normal)
>>> file-storage-3982 [006] d... 131.010674: dwc3_gadget_ep_cmd: ep1in: cmd 'Update Transfer' [30007] params 00000000 00000000 00000000 --> status: Successful
>>> irq/16-dwc3-3983 [004] d... 131.010942: dwc3_event: event (00004086): ep1in: Transfer In Progress [0] (sIm)
>>> irq/16-dwc3-3983 [004] d... 131.010942: dwc3_complete_trb: ep1in: trb 00000000426cd8cf buf 00000000bde20000 size 0 ctrl 00000810 (hlcs:sC:normal)
>>> irq/16-dwc3-3983 [004] d... 131.010944: dwc3_gadget_giveback: ep1in: req 00000000f7765e56 length 16384/16384 zsI ==> 0
>>> file-storage-3982 [006] d... 131.010994: dwc3_ep_queue: ep1in: req 00000000f7765e56 length 0/16384 zsI ==> -115
>>> file-storage-3982 [006] d... 131.010998: dwc3_prepare_trb: ep1in: trb 0000000065d9143d buf 00000000bde28000 size 16384 ctrl 00000811 (Hlcs:sC:normal)
>>> file-storage-3982 [006] d... 131.011005: dwc3_gadget_ep_cmd: ep1in: cmd 'Update Transfer' [30007] params 00000000 00000000 00000000 --> status: Successful
>>> irq/16-dwc3-3983 [004] d... 131.065517: dwc3_event: event (00000001): Disconnect: [U0]
>>> file-storage-3982 [006] .... 131.065558: dwc3_ep_dequeue: ep1in: req 00000000f7765e56 length 0/16384 zsI ==> -115
>>> file-storage-3982 [006] d... 131.065687: dwc3_gadget_ep_cmd: ep1in: cmd 'End Transfer' [30d08] params 00000000 00000000 00000000 --> status: Successful
>>> irq/16-dwc3-3983 [004] d... 131.065729: dwc3_event: event (080301c6): ep1in: Endpoint Command Complete
>>> irq/16-dwc3-3983 [004] d... 131.065731: dwc3_gadget_giveback: ep1in: req 00000000f7765e56 length 0/16384 zsI ==> -104
>>> file-storage-3982 [006] .... 131.065766: dwc3_ep_dequeue: ep1in: req 00000000eccaa10f length 0/16384 zsI ==> -115
>>> irq/16-dwc3-3983 [004] d... 135.071714: dwc3_event: event (00000101): Reset [U0]
>>> irq/16-dwc3-3983 [004] d... 135.126440: dwc3_event: event (00000201): Connection Done [U0]
>>>
>>> From this snippet above it seems like we got End Transfer completed
>>> *before* we tried to dequeue the request. This is a race in the driver,
>>> since it will wait for End Transfer complete forever :-p We can see that
>>> ep_dequeue won't send a new End Transfer unless it's necessary:
Right. That was what I try to point in my previous reply.
>>>
>>> static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force)
>>> {
>>> struct dwc3 *dwc = dep->dwc;
>>> struct dwc3_gadget_ep_cmd_params params;
>>> u32 cmd;
>>> int ret;
>>>
>>> if ((dep->flags & DWC3_EP_END_TRANSFER_PENDING) ||
>>> !dep->resource_index)
>>> return;
>>> [...]
>>> }
>>>
>>> So this will wait forever. Here's a patch that takes into consideration
>>> this possibility:
>> a version that compiles now (#facepalm):
> I've prepared a branch with a few patches on top of my testing/fixes to
> test this out. Seems to work fine on my end. Can you try with your test
> setup?
I think you need to fix this:
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 1b7c44271b11..73e3a402f63d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2621,7 +2621,7 @@ static void dwc3_stop_active_transfer(struct
dwc3_ep *dep, bool force)
u32 cmd;
int ret;
- if (dep->flags & DWC3_EP_TRANSFER_STARTED)
+ if (!(dep->flags & DWC3_EP_TRANSFER_STARTED))
return;
/*
Other than that, these changes seem to fix the issue.
Thanks,
Thinh
