Hi, > On Wed, May 12, 2010 at 05:19:38PM +0530, Ajay Kumar Gupta wrote: > > MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires > > the buffers to be aligned on a four byte boundary. This affects USB > > CDC/RNDIS class application where buffers are always unaligned. > > > > Use system DMA for unaligned buffers as a workaround of this issue. > > > > Current patch supports device side CDC/RNDIS. Host side would require > > change in Tx programming path for mode-0 operation when transfer length > > is more than packet size. > > > > Also fixed an issue in device Tx completion path where 'is_dma' is > getting > > set unconditionally. This would fail the io if Tx transfer is done in > > mode-0. Fixed it by updating it based on 'request->actual' length. > > > > Signed-off-by: Ajay Kumar Gupta <ajay.gu...@ti.com> > > [..] > > > @@ -166,6 +166,12 @@ config MUSB_USE_SYSTEM_DMA_WORKAROUND > > DMA channels are simultaneously enabled. To work around this > issue, > > you can choose to use System DMA for RX channels. > > > > + Also on Mentor DMA in MUSB RTL version 1.8 (OMAP3630, AM/DM37x) > > + requires buffers to be aligned on a four byte boundary. This > affects > > + USB CDC/RNDIS class application where buffers are always > unaligned. > > + To work around this issue, you can choose to use System DMA for > > + unaligned buffers. > > instead of this patch, it's a whole lot easier to simply use a bounce > buffer: > > if (unaligned) { > bounce = dma_alloc_coherent(......); > memcpy(request->buf, bounce, request->length); > }
How about this 'memcpy', this would affect both cpu loading and performance. That's why using system dma would be a better approach. -Ajay > > and use that buffer on channel_program(); > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html