diff options
| author | Thinh Nguyen <Thinh.Nguyen@synopsys.com> | 2019-12-18 18:14:56 -0800 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2020-01-15 10:39:23 +0100 |
| commit | cf2f8b63f7f1f6763e4fcdf89145312224ee736b (patch) | |
| tree | 82504e93b38f3793c294ae4168800bbd42d85d7e /drivers/usb/dwc3 | |
| parent | da10bcdd6f70dc9977f2cf18f4783cf78520623a (diff) | |
usb: dwc3: gadget: Remove END_TRANSFER delay
We had a 100us delay to synchronize the END_TRANSFER command completion
before giving back requests to the function drivers. Now, the controller
driver can handle cancelled TRBs with the requests' cancelled_list and
it can also wait until the END_TRANSFER completion before starting new
transfers. Synchronization can simply base on the controller's command
completion interrupt. The 100us delay is no longer needed. Remove this
arbitrary delay.
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/usb/dwc3')
| -rw-r--r-- | drivers/usb/dwc3/gadget.c | 18 |
1 files changed, 5 insertions, 13 deletions
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 696fbeb8d03a..1b8014ab0b25 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2693,7 +2693,6 @@ static void dwc3_reset_gadget(struct dwc3 *dwc) static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force, bool interrupt) { - struct dwc3 *dwc = dep->dwc; struct dwc3_gadget_ep_cmd_params params; u32 cmd; int ret; @@ -2709,16 +2708,13 @@ static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force, * much trouble synchronizing between us and gadget driver. * * We have discussed this with the IP Provider and it was - * suggested to giveback all requests here, but give HW some - * extra time to synchronize with the interconnect. We're using - * an arbitrary 100us delay for that. + * suggested to giveback all requests here. * * Note also that a similar handling was tested by Synopsys * (thanks a lot Paul) and nothing bad has come out of it. - * In short, what we're doing is: - * - * - Issue EndTransfer WITH CMDIOC bit set - * - Wait 100us + * In short, what we're doing is issuing EndTransfer with + * CMDIOC bit set and delay kicking transfer until the + * EndTransfer command had completed. * * As of IP version 3.10a of the DWC_usb3 IP, the controller * supports a mode to work around the above limitation. The @@ -2727,8 +2723,7 @@ static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force, * by writing GUCTL2[14]. This polling is already done in the * dwc3_send_gadget_ep_cmd() function so if the mode is * enabled, the EndTransfer command will have completed upon - * returning from this function and we don't need to delay for - * 100us. + * returning from this function. * * This mode is NOT available on the DWC_usb31 IP. */ @@ -2746,9 +2741,6 @@ static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force, dep->flags &= ~DWC3_EP_TRANSFER_STARTED; else dep->flags |= DWC3_EP_END_TRANSFER_PENDING; - - if (dwc3_is_usb31(dwc) || dwc->revision < DWC3_REVISION_310A) - udelay(100); } static void dwc3_clear_stall_all_ep(struct dwc3 *dwc) |