Re: [Question] which type of DMA taken by musb of beagle-xM(DM3730)?

[Anand Gadiyar <gadiyar@ti.com>]

On 10/27/2010 11:27 AM, Ming Lei wrote:
> 2010/10/27 Anand Gadiyar<gadiyar@ti.com>:
>> On 10/27/2010 10:55 AM, Ming Lei wrote:
>>>
>>> 2010/10/27 Ming Lei<tom.leiming@gmail.com>:
>>>>
>>>> Hi Gadiyar,
>>>>
>>>> Thanks for your reply.
>>>>
>>>> 2010/10/27 Gadiyar, Anand<gadiyar@ti.com>:
>>>>>
>>>>> On Wed, Oct 27, 2010 at 5:54 AM, Ming Lei<tom.leiming@gmail.com>    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