On 12/13/2010 2:35 PM, Artem Leonenko wrote: > There is one nasty scenario when CI13xxx driver fails: > a) two or more rx requests are queued (g_ether does that) > b) rx request completed, interrupt fires and ci13xxx dequeues rq > c) request complete() callback gets called and in turn it calls > ep_queue() > c1) in ep_queue() request gets added to the TAIL of the > rx queue list > d) ep gets primed with rq from (b) > e) interrupt fires > f) request gets popped from queue head for hw dequeue > G) requets from queue head wasn't enqueued > g1) isr_tr_complete_low() doesn't > enqueue more requests and it doesn't prime EP, > rx traffic stalls > > Solution: > a) enque queued requests ASAP, i.e. before calling complete() > callback. > b) don't HW enqueue and prime endpoint with recently added > request and > use the oldest request in the queue. > > Fixed issues: > a) ep_queue() may return an error code despite request was > successfully > added to the queue (if _hardware_enqueue() fails) > b) Added requests are always processed in LIFO order, even if > they are > added in complete() callback > c) Finally more than two and more queued requests are processed > consistently, > even if they were added in complete() callback > > The fix was successfully tested on MIPS based SoC with 4KEc CPU core and > CI13612 USB core. Board successfully boots with NFS root using g_ether > on ci13xxx udc. > > Signed-off-by: Artem Leonenko <tikkeri@xxxxxxxxx> > --- > drivers/usb/gadget/ci13xxx_udc.c | 20 ++++++++++++-------- > 1 files changed, 12 insertions(+), 8 deletions(-) > This patch looks fine. I have verified g_ether (ping test) on MSM Soc. Thanks, Pavan -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
