Hi Thinh,
On 3/1/2023 2:44 PM, Thinh Nguyen wrote:
On Tue, Feb 28, 2023, Wesley Cheng wrote:
Previously, there was a 100uS delay inserted after issuing an end transfer
command for specific controller revisions. This was due to the fact that
there was a GUCTL2 bit field which enabled synchronous completion of the
end transfer command once the CMDACT bit was cleared in the DEPCMD
register. Since this bit does not exist for all controller revisions, add
Can we also note here that we rely on End Transfer command completion
interrupt on newer versions.
the delay back in, and increase the duration to 1ms for the controller to
complete the command.
An issue was seen where the USB request buffer was unmapped while the DWC3
controller was still accessing the TRB. However, it was confirmed that the
end transfer command was successfully submitted. (no end transfer timeout)
In situations, such as dwc3_gadget_soft_disconnect() and
__dwc3_gadget_ep_disable(), the dwc3_remove_request() is utilized, which
will issue the end transfer command, and follow up with
dwc3_gadget_giveback(). At least for the USB ep disable path, it is
required for any pending and started requests to be completed and returned
to the function driver in the same context of the disable call. Without
the GUCTL2 bit, it is not ensured that the end transfer is completed before
the buffers are unmapped.
I think this also needs a Fixes tag.
Everything else looks good to me.
Thanks for the reviews, Thinh. Will fix the above and resubmit.
Thanks
Wesley Cheng
