[U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce

[Marek Vasut]

Dear Troy Kisky,

> On 9/22/2013 5:02 PM, Marek Vasut wrote:
> > Dear Troy Kisky,
> > 
> >> On 9/20/2013 3:58 AM, Marek Vasut wrote:
> >>> Dear Troy Kisky,
> >>> 
> >>>> Only perform one copy, either in the bounce
> >>>> routine for IN transfers, or the debounce
> >>>> rtn for OUT transfer.
> >>>> 
> >>>> On out transfers, only copy the number
> >>>> of bytes received from the bounce buffer
> >>>> 
> >>>> Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
> >>>> 
> >>>> ---
> >>>> v4: no change
> >>> 
> >>> Just a question here. Are you sure we never Send AND Reserve the data
> >>> in one turn? Because that would need two copyings.
> >>> 
> >>    ???   s/Reserve/Receive/
> >> 
> >> As far as I'm aware, a single buffer is only ever used to capture or
> >> provide data not both.
> >> But, if 2 transfers were queued, an OUT and then an IN using the same
> 
> Actually, I should have said "an IN (tx to the host controller) and then
> an OUT(rx from the host controller)"
> 
> >> buffer, if it worked before
> >> this patch, it should work after as well.
> > 
> > How come? Before, it was doing flush before and inval after the transfer,
> > right ?
> 
> The 1st "IN" transfer (tx to the host), will [copy]/flush on mv_bounce
> and [free]/nothing on mv_debounce.
> The 2nd "OUT" transfer (rx from the host) will flush on mv_bounce and
> invalidate/[copy/free] on mv_debounce.
> 
> > btw what does this part of the patch do/mean ? Why is it there?
> > 
> > @@ -387,10 +383,9 @@ static void handle_ep_complete(struct mv_ep *ep)
> > 
> >                         num, in ? "in" : "out", item->info, item->page0);
> >          
> >          len = (item->info >> 16) & 0x7fff;
> > 
> > -
> > -       mv_debounce(ep);
> > -
> > 
> >          ep->req.length -= len;
> > 
> > +       mv_debounce(ep, in);
> > +
> 
> That implements the "On out transfers, only copy the number of bytes
> received from the bounce buffer"
> portion of the commit message.

OK, thanks.

Best regards,
Marek Vasut