Hello, 2010/10/27 Anand Gadiyar <gadiyar@xxxxxx>: > On 10/27/2010 10:55 AM, Ming Lei wrote: >> >> 2010/10/27 Ming Lei<tom.leiming@xxxxxxxxx>: >>> >>> Hi Gadiyar, >>> >>> Thanks for your reply. >>> >>> 2010/10/27 Gadiyar, Anand<gadiyar@xxxxxx>: >>>> >>>> On Wed, Oct 27, 2010 at 5:54 AM, Ming Lei<tom.leiming@xxxxxxxxx> wrote: >>>>> >>>>> I want to know which type of DMA is taken by musb of DM3730, >>>>> INVENTRA_DMA, TI_CPPI_DMA or others? >>>> >>>> Inventra DMA. An updated version compared to the OMAP34xx/35xx. >>>> >>>> - No major change to the programming model >>>> - The simultaneous TX-RX DMA hang bug is gone with this one. >>> >>> I find one issue about the dma transfer if Inventra DMA is used, seems >>> always 2 bytes less than required length, is it caused by unaligned >>> destination address? >>> >>> See the log captured in g_ether context: >>> > > Ouch, yes. I'd forgotten about this one. I think I did post out patches for > this. But I've moved to other activities and didn't follow up. I'll dig them > up and post in a bit. > > The issue is that, by design, the last 2 bits of DMA_ADDR are masked by the > DMA engine; so we need DMA_ADDR to be aligned to a 32-bit boundary. > > In gadget mode, g_ether is one driver that's badly affected - there were > some patches posted which improved g_ether somewhat. In host mode, > USB-networking cases were most affected. MUSB has two options: > > - dma_channel_program can reject transfers to unaligned DMA addresses, so > that the backup PIO mode can take over (a quick fix - I'll post this one > again) > > - MUSB can bounce the transfer buffer to another buffer which is properly > aligned > > Any other ideas? Another question, musb_read_fifo and musb_write_fifo need to be fixed to use 32bit operation only alike am35x? thanks, -- Lei Ming -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
