Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce
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.ki...@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. Thanks Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce
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.ki...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce
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.ki...@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 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 ? 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); + DBG(ept%d %s complete %x\n, num, in ? in : out, len); ep-req.complete(ep-ep, ep-req); Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce
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.ki...@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. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 10/17] usb: gadget: mv_udc: optimize bounce
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.ki...@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 buffer, if it worked before this patch, it should work after as well. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot