Commit 57911504 authored by Pratyush Anand's avatar Pratyush Anand Committed by Felipe Balbi

usb: dwc3: gadget: Fix dwc3_stop_active_transfer for synchronization delay

dwc3_stop_active_transfer has been called from two places. After each
calling of this function , we should allow 100 us delay to synchronize
with interconnect.

It would be better if we put this delay in that function only, rather
than into calling routine of this function.
Signed-off-by: default avatarPratyush Anand <pratyush.anand@st.com>
Reported-by: default avatarMichel Sanches <michel.sanches@st.com>
Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
parent 79c9046e
...@@ -563,27 +563,7 @@ static void dwc3_remove_requests(struct dwc3 *dwc, struct dwc3_ep *dep) ...@@ -563,27 +563,7 @@ static void dwc3_remove_requests(struct dwc3 *dwc, struct dwc3_ep *dep)
if (!list_empty(&dep->req_queued)) { if (!list_empty(&dep->req_queued)) {
dwc3_stop_active_transfer(dwc, dep->number); dwc3_stop_active_transfer(dwc, dep->number);
/* /* - giveback all requests to gadget driver */
* NOTICE: We are violating what the Databook says about the
* EndTransfer command. Ideally we would _always_ wait for the
* EndTransfer Command Completion IRQ, but that's causing too
* 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 arbitraty 100us delay for that.
*
* 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
* - giveback all requests to gadget driver
*/
udelay(100);
while (!list_empty(&dep->req_queued)) { while (!list_empty(&dep->req_queued)) {
req = next_request(&dep->req_queued); req = next_request(&dep->req_queued);
...@@ -1875,6 +1855,25 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, u32 epnum) ...@@ -1875,6 +1855,25 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, u32 epnum)
if (!dep->resource_index) if (!dep->resource_index)
return; return;
/*
* NOTICE: We are violating what the Databook says about the
* EndTransfer command. Ideally we would _always_ wait for the
* EndTransfer Command Completion IRQ, but that's causing too
* 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 arbitraty 100us delay for that.
*
* 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
*/
cmd = DWC3_DEPCMD_ENDTRANSFER; cmd = DWC3_DEPCMD_ENDTRANSFER;
cmd |= DWC3_DEPCMD_HIPRI_FORCERM | DWC3_DEPCMD_CMDIOC; cmd |= DWC3_DEPCMD_HIPRI_FORCERM | DWC3_DEPCMD_CMDIOC;
cmd |= DWC3_DEPCMD_PARAM(dep->resource_index); cmd |= DWC3_DEPCMD_PARAM(dep->resource_index);
...@@ -1882,6 +1881,8 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, u32 epnum) ...@@ -1882,6 +1881,8 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, u32 epnum)
ret = dwc3_send_gadget_ep_cmd(dwc, dep->number, cmd, &params); ret = dwc3_send_gadget_ep_cmd(dwc, dep->number, cmd, &params);
WARN_ON_ONCE(ret); WARN_ON_ONCE(ret);
dep->resource_index = 0; dep->resource_index = 0;
udelay(100);
} }
static void dwc3_stop_active_transfers(struct dwc3 *dwc) static void dwc3_stop_active_transfers(struct dwc3 *dwc)
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment