Commit ea53b882 authored by Felipe Balbi's avatar Felipe Balbi
Browse files

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: default avatarPratyush Anand <pratyush.anand@st.com>
Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
parent 6dbc10c6

drivers/usb/dwc3/gadget.c

+27 −39
Original line number Diff line number Diff line
@@ -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;

	}

}