Hello.
On 23-12-2010 21:30, Sergei Shtylyov wrote:
musb_gadget_dequeue() doesn't start the next request when dequeuing the current
one, but quite obviously it should...
Not quite as obvious as it turns out, as the next endpoint interrupt
should really take care of the next request. So this patch doesn't seem
necessary anymore...
Signed-off-by: Sergei Shtylyov<sshtylyov@xxxxxxxxxxxxx>
---
This patch is against the recent Linus' tree.
drivers/usb/musb/musb_gadget.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
Index: usb-2.6/drivers/usb/musb/musb_gadget.c
===================================================================
--- usb-2.6.orig/drivers/usb/musb/musb_gadget.c
+++ usb-2.6/drivers/usb/musb/musb_gadget.c
@@ -1262,11 +1262,13 @@ static int musb_gadget_dequeue(struct us
}
/* if the hardware doesn't have the request, easy ... */
- if (musb_ep->req_list.next !=&request->list || musb_ep->busy)
+ if (musb_ep->req_list.next !=&request->list || musb_ep->busy) {
musb_g_giveback(musb_ep, request, -ECONNRESET);
+ goto done;
+ }
- /* ... else abort the dma transfer ... */
- else if (is_dma_capable()&& musb_ep->dma) {
+ /* ... else abort the DMA transfer ... */
+ if (is_dma_capable()&& musb_ep->dma) {
struct dma_controller *c = musb->dma_controller;
musb_ep_select(musb->mregs, musb_ep->current_epnum);
@@ -1274,13 +1276,17 @@ static int musb_gadget_dequeue(struct us
status = c->channel_abort(musb_ep->dma);
else
status = -EBUSY;
- if (status == 0)
- musb_g_giveback(musb_ep, request, -ECONNRESET);
- } else {
+ }
+
+ if (status == 0) {
/* NOTE: by sticking to easily tested hardware/driver states,
* we leave counting of in-flight packets imprecise.
*/
musb_g_giveback(musb_ep, request, -ECONNRESET);
What can be done still is merging the two branches as I've done here...
+
+ request = next_request(musb_ep);
+ if (request)
+ musb_ep_restart(musb, to_musb_request(request));
}
done:
WBR, Sergei
--
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
