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?
- Anand
--
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
