[PATCH V2 1/3] usb/dwc3:Move udelay within stop_active_transfe

[Pratyush Anand]

We need udelay(100) after every END TRANSFER, so it is better to keep it
within dwc3_stop_active_transfer.

Signed-off-by: Pratyush Anand <pratyush.an...@st.com>
---
 drivers/usb/dwc3/gadget.c |   42 +++++++++++++++++++++---------------------
 1 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index cc8834c..9699723 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -566,27 +566,6 @@ static void dwc3_remove_requests(struct dwc3 *dwc, struct 
dwc3_ep *dep)
        if (!list_empty(&dep->req_queued)) {
                dwc3_stop_active_transfer(dwc, dep->number);
 
-               /*
-                * 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)) {
                        req = next_request(&dep->req_queued);
 
@@ -1927,6 +1906,27 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, 
u32 epnum)
        ret = dwc3_send_gadget_ep_cmd(dwc, dep->number, cmd, &params);
        WARN_ON_ONCE(ret);
        dep->resource_index = 0;
+
+       /*
+        * 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);
 }
 
 static void dwc3_stop_active_transfers(struct dwc3 *dwc)
-- 
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html