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

[Pratyush Anand <pratyush.anand@xxxxxx>]

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.anand@xxxxxx>
---
 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html