Subject: Re: [RFC] [PATCH] usb: gadget: fix dtd dma confusion

From: Greg Kroah-Hartman <[email-masked]>
Date: Sun, 13 May 2012 21:21:42 -0700

On Mon, May 14, 2012 at 12:51:26AM +0200, Christoph Fritz wrote:
> On Wed, May 09, 2012 at 02:02:22AM +0200, Christoph Fritz wrote:
> > 
> > Hi to All,
> > 
> > after a while of testing and searching I can come up with a patch
> > that fixes g_ether <-> iperf for fsl_udc on ARM i.MX35.
> > 
> > The sad part is that this kind of fix is already implemented for
> > marvell mv_udc driver since last year but still _not_ in the ~15
> > other *udc.c drivers.
> > 
> > See here:
> > daec765da767e4a6a30e1298862b28f2cae9a73f
> > usb: gadget: mv_udc: fix dtd dma confusion
> > 
> > So hereby I'm CC-ing all *udc.c maintainers to point out that this
> > issue maybe affects you too.
> > 
> > 
> > ---
> > Subject: [PATCH] usb: gadget: fsl_udc: fix dtd dma confusion
> > 
> > The controller will hang when doing testings with g_ether and iperf
> > (tool for measuring maximum TCP and UDP bandwidth).  This patch adds a
> > delay to wait for controller to release dtd dma before freeing it.
> > 
> > Signed-off-by: Christoph Fritz <[email-masked]>
> > ---
> >  drivers/usb/gadget/fsl_udc_core.c |    9 +++++++++
> >  1 files changed, 9 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
> > index 55abfb6..fc86108 100644
> > --- a/drivers/usb/gadget/fsl_udc_core.c
> > +++ b/drivers/usb/gadget/fsl_udc_core.c
> > @@ -1638,6 +1638,15 @@ static int process_ep_req(struct fsl_udc *udc, int pipe,
> >  			status = REQ_UNCOMPLETE;
> >  			return status;
> >  		} else if (remaining_length) {
> > +			/* wait controller release dtd dma */
> > +			while ((curr_qh->curr_dtd_ptr == curr_td->td_dma)) {
> > +				if (curr_td->next_td_ptr ==
> > +						EP_QUEUE_HEAD_NEXT_TERMINATE) {
> > +					udelay(100);
> > +					break;
> > +				}
> > +				udelay(1);
> > +			}
> >  			if (direction) {
> >  				VDBG("Transmit dTD remaining length not zero");
> >  				status = -EPROTO;
> > -- 
> > 1.7.2.5
> 
>  ping  -  what about this patch? Will it be applied?

RFC patches are never applied, as you are asking for comments, not for
the patch to actually be applied...

Submit it properly if you wish it to be accepted.

thanks,

greg k-h