[PATCH 12/22] usb: dwc3: gadget: start bulk endpoints more frequently

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Instead of waiting for !BUSY, we can kick bulk
endpoints more frequently and rely on the fact that
__dwc3_gadget_kick_transfer() will use Update
Transfer if BUSY flag is set.

Signed-off-by: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx>
---
 drivers/usb/dwc3/gadget.c | 47 +++++++++++++++--------------------------------
 1 file changed, 15 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 809445ec6a87..f9f7fe2c1e14 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1080,18 +1080,6 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
 
 	trace_dwc3_ep_queue(req);
 
-	/*
-	 * We only add to our list of requests now and
-	 * start consuming the list once we get XferNotReady
-	 * IRQ.
-	 *
-	 * That way, we avoid doing anything that we don't need
-	 * to do now and defer it until the point we receive a
-	 * particular token from the Host side.
-	 *
-	 * This will also avoid Host cancelling URBs due to too
-	 * many NAKs.
-	 */
 	ret = usb_gadget_map_request(&dwc->gadget, &req->request,
 			dep->direction);
 	if (ret)
@@ -1100,28 +1088,24 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
 	list_add_tail(&req->list, &dep->pending_list);
 
 	/*
-	 * If there are no pending requests and the endpoint isn't already
-	 * busy, we will just start the request straight away.
+	 * If this is a bulk endpoint, then just issue Start Transfer or Update
+	 * Transfer straight away. This will possibly avoid a few XferNotReady
+	 * events and let us recycle a struct usb_request earlier.
 	 *
-	 * This will save one IRQ (XFER_NOT_READY) and possibly make it a
-	 * little bit faster.
 	 */
 	if (!usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
-			!usb_endpoint_xfer_int(dep->endpoint.desc) &&
-			!(dep->flags & DWC3_EP_BUSY)) {
+			!usb_endpoint_xfer_int(dep->endpoint.desc)) {
 		ret = __dwc3_gadget_kick_transfer(dep, 0);
 		goto out;
 	}
 
 	/*
-	 * There are a few special cases:
-	 *
-	 * 1. XferNotReady with empty list of requests. We need to kick the
-	 *    transfer here in that situation, otherwise we will be NAKing
-	 *    forever. If we get XferNotReady before gadget driver has a
-	 *    chance to queue a request, we will ACK the IRQ but won't be
-	 *    able to receive the data until the next request is queued.
-	 *    The following code is handling exactly that.
+	 * XferNotReady with empty list of requests. We need to kick the
+	 * transfer here in that situation, otherwise we will be NAKing
+	 * forever. If we get XferNotReady before gadget driver has a chance to
+	 * queue a request, we will ACK the IRQ but won't be able to receive the
+	 * data until the next request is queued.  The following code is
+	 * handling exactly that.
 	 *
 	 */
 	if (dep->flags & DWC3_EP_PENDING_REQUEST) {
@@ -1147,9 +1131,9 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
 	}
 
 	/*
-	 * 2. XferInProgress on Isoc EP with an active transfer. We need to
-	 *    kick the transfer here after queuing a request, otherwise the
-	 *    core may not see the modified TRB(s).
+	 * XferInProgress on Isoc EP with an active transfer. We need to kick
+	 * the transfer here after queuing a request, otherwise the core may not
+	 * see the modified TRB(s).
 	 */
 	if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
 			(dep->flags & DWC3_EP_BUSY) &&
@@ -1160,9 +1144,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
 	}
 
 	/*
-	 * 4. Stream Capable Bulk Endpoints. We need to start the transfer
-	 * right away, otherwise host will not know we have streams to be
-	 * handled.
+	 * Stream Capable Bulk Endpoints. We need to start the transfer right
+	 * away, otherwise host will not know we have streams to be handled.
 	 */
 	if (dep->stream_capable)
 		ret = __dwc3_gadget_kick_transfer(dep, 0);
-- 
2.8.2

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux