Hi, >-----Original Message----- >From: Balbi, Felipe >Sent: Monday, November 15, 2010 5:19 PM >To: Kalliguddi, Hema >Cc: linux-usb@xxxxxxxxxxxxxxx; Balbi, Felipe >Subject: Re: [PATCH V2] usb: musb: Unmapping the dma buffer >when switching to PIO mode > >On Mon, Nov 15, 2010 at 04:24:01AM -0600, Kalliguddi, Hema wrote: >>Buffer is mapped to dma when dma channel is allocated. buffer needs >>to be unmapped when fallback to PIO mode if dma channel_program >>fails. >> >>g_ether use to fail on OMAp3630 as there were unaligned >buffers being sent. >>With this patch and [1] g_ether works fine. >>[1]:http://www.spinics.net/lists/linux-usb/msg38400.html >> >>Signed-off-by: Hema HK <hemahk@xxxxxx> >>Cc: Felipe Balbi <balbi@xxxxxx> > >applied, thanks. > >I brushed the commit log a little bit, please verify it's ok: > >commit fd542305e10f85b1f46c71daf8b6ddd12f15fa82 >Author: Hema Kalliguddi <hemahk@xxxxxx> >Date: Mon Nov 15 04:24:01 2010 -0600 > > usb: musb: unmap dma buffer when switching to PIO > > Buffer is mapped to dma when dma channel is > allocated. If, for some reason, dma channel > programming fails, musb code will fallback > to PIO mode to transfer that request. In > that case, we need to unmap the buffer > back to CPU. > > MUSB RTL1.8 cannot handle buffers which are > not 32bit aligned. That happens to every > request sent by g_ether gadget driver. Since > the buffer sent was unaligned, we need to > fallback to PIO. > Just one minor addition. MUSB RTL1.8 and above cannot handle buffers which are not 32bit aligned Thanks, Hema > Because of that, g_ether was failing due > to missing buffer unmapping. > > With this patch and [1] g_ether works fine > with all MUSB revisions. > > Verified with OMAP3630 board, which has > MUSB RTL1.8 using g_ether and g_zero. > > [1] http://www.spinics.net/lists/linux-usb/msg38400.html > > Signed-off-by: Hema HK <hemahk@xxxxxx> > Signed-off-by: Felipe Balbi <balbi@xxxxxx> > >-- >balbi >-- 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
