usb: dwc3: gadget: don't wait for ep cmd IRQ

That IRQ is causing way too much trouble. We have
a different handling which was agreed with IP
provider and has been tested with FPGA and OMAP5.

Tested-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 056ace8ab97d6e0abf71c91fcd8cd5b55ef80dc1..0f19978d484000d12a9b8e716d51ef6f8997b61b 100644 (file)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -555,9 +555,34 @@ static void dwc3_remove_requests(struct dwc3 *dwc, struct dwc3_ep *dep)
 {
        struct dwc3_request             *req;
 
-       if (!list_empty(&dep->req_queued))
+       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);
+
+               req = next_request(&dep->req_queued);
+               dwc3_gadget_giveback(dep, req, -ESHUTDOWN);
+       }
+
        while (!list_empty(&dep->request_list)) {
                req = next_request(&dep->request_list);
 
@@ -1735,43 +1760,6 @@ static void dwc3_endpoint_transfer_complete(struct dwc3 *dwc,
        }
 }
 
-static void dwc3_process_ep_cmd_complete(struct dwc3_ep *dep,
-               const struct dwc3_event_depevt *event)
-{
-       struct dwc3 *dwc = dep->dwc;
-       struct dwc3_event_depevt mod_ev = *event;
-
-       /*
-        * We were asked to remove one request. It is possible that this
-        * request and a few others were started together and have the same
-        * transfer index. Since we stopped the complete endpoint we don't
-        * know how many requests were already completed (and not yet)
-        * reported and how could be done (later). We purge them all until
-        * the end of the list.
-        */
-       mod_ev.status = DEPEVT_STATUS_LST;
-       dwc3_cleanup_done_reqs(dwc, dep, &mod_ev, -ESHUTDOWN);
-       dep->flags &= ~DWC3_EP_BUSY;
-       /* pending requests are ignored and are queued on XferNotReady */
-}
-
-static void dwc3_ep_cmd_compl(struct dwc3_ep *dep,
-               const struct dwc3_event_depevt *event)
-{
-       u32 param = event->parameters;
-       u32 cmd_type = (param >> 8) & ((1 << 5) - 1);
-
-       switch (cmd_type) {
-       case DWC3_DEPCMD_ENDTRANSFER:
-               dwc3_process_ep_cmd_complete(dep, event);
-               break;
-       default:
-               printk(KERN_ERR "%s() unknown /unexpected type: %d\n",
-                               __func__, cmd_type);
-               break;
-       };
-}
-
 static void dwc3_endpoint_interrupt(struct dwc3 *dwc,
                const struct dwc3_event_depevt *event)
 {
@@ -1853,7 +1841,7 @@ static void dwc3_endpoint_interrupt(struct dwc3 *dwc,
                dev_dbg(dwc->dev, "%s FIFO Overrun\n", dep->name);
                break;
        case DWC3_DEPEVT_EPCMDCMPLT:
-               dwc3_ep_cmd_compl(dep, event);
+               dev_vdbg(dwc->dev, "Endpoint Command Complete\n");
                break;
        }
 }