On 10/27/2010 11:27 AM, Ming Lei wrote:
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
Seems such design of DMA engine is a regression in chip, :-(
Both the two options may degrade performance a lot, at least
for g_ether application.
I don't think there is better fix in software than the two ones
you posted.
Looking at old mail threads, I remember Ajay had one objection to using
PIO for unaligned transfers - when multiple DMA channels are repeatedly
hit with unaligned DMA addresses, throughput and CPU load go for a toss.
Ajay wanted to use the OMAP's SystemDMA engine to carry out the
transfers in those cases. Anyway, that's a separate topic - and should
probably be done after the DMA code is rewritten. (I think Felipe had
some plans for that).
I've posted a patch implementing the quick fix. Let me know if it solves
the problem with g_ether.
While fixing this, I noticed dma_channel_program also returns "true"
while it is supposed to return an "int". Topic for a separate patch.
- Anand
--
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
