On Thu, Jul 13, 2023, William Wu wrote: > If miss isoc event happens, the current code just set > the req status to -EXDEV and giveback the req to the usb > gadget driver, and then stop the active transfer with the > cmd DWC3_DEPCMD_ENDTRANSFER and wait for a XferNotReady > event to restart a transfer again. However, for isoc > ep in transfer, it cause to lost the isoc data of the > req. That's intentional and expected behavior. > > This patch moves the miss isoc req to pending_list in > order to restart transfer immediately instead of give > back the req to the usb gadget driver. No. Now you're breaking the usage of isoc endpoint and also re-ordering the transfer sequence. > > Signed-off-by: William Wu <william.wu@xxxxxxxxxxxxxx> Regardless of direction, isoc data is time sensitive. If an isoc request (or part of it) does not go out at a scheduled interval, then it's dropped. You should look into why it's being dropped (whether it's due to software or hardware latency) and see if you can help it. If your application does not care about the timing, then perhaps it should use a different endpoint type. If your application protocol requires the use of isoc endpoint and somehow also demands no data drop tolerance, then you can workaround that from the gadget driver. However I doubt this is the case. BR, Thinh
