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

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

[Ming Lei]

Hi,

I want to know which type of DMA is taken by musb of DM3730,
INVENTRA_DMA, TI_CPPI_DMA or others?


thanks,
-- 
Lei Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Gadiyar, Anand]

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.

- Anand

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

[Ming Lei]

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:

......
musb_g_rx 765: <== ep1out, rxcsr 0003 (dma) dec241c0
dma_channel_program 165: ep1-Rx pkt_sz 512, dma_addr 0x9ecc7802 length
70, mode 0
configure_channel 130: dec57068, pkt_sz 512, addr 0x9ecc7802, len 70, mode 0
dma_controller_irq 302: ch dec57068, 0x9ecc7802 -> 0x9ecc7846 (68 /
70) => reconfig 0
musb_g_rx 765: <== ep1out, rxcsr 2003 (dma) dec241c0
musb_g_rx 808: RXCSR1 0003, dma off, 0003, len 68, req dec241c0
musb_g_giveback 143: ep1out done request dec241c0,  68/1536
musb_gadget_queue 1146: <== to ep1out request=dec241c0
musb_interrupt 1594: ** IRQ peripheral usb0008 tx0000 rx0002
musb_stage0_irq 462: <== Power=f0, DevCtl=99, int_usb=0x8
musb_g_rx 765: <== ep1out, rxcsr 0003 (dma) dec244c0
dma_channel_program 165: ep1-Rx pkt_sz 512, dma_addr 0x9ecc7002 length
341, mode 0
configure_channel 130: dec57068, pkt_sz 512, addr 0x9ecc7002, len 341, mode 0
dma_controller_irq 302: ch dec57068, 0x9ecc7002 -> 0x9ecc7155 (339 /
341) => reconfig 0
......


thanks,
-- 
Lei Ming

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

[Ming Lei]

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:
>
> ......
> musb_g_rx 765: <== ep1out, rxcsr 0003 (dma) dec241c0
> dma_channel_program 165: ep1-Rx pkt_sz 512, dma_addr 0x9ecc7802 length
> 70, mode 0
> configure_channel 130: dec57068, pkt_sz 512, addr 0x9ecc7802, len 70, mode 0
> dma_controller_irq 302: ch dec57068, 0x9ecc7802 -> 0x9ecc7846 (68 /
> 70) => reconfig 0
> musb_g_rx 765: <== ep1out, rxcsr 2003 (dma) dec241c0
> musb_g_rx 808: RXCSR1 0003, dma off, 0003, len 68, req dec241c0
> musb_g_giveback 143: ep1out done request dec241c0,  68/1536
> musb_gadget_queue 1146: <== to ep1out request=dec241c0
> musb_interrupt 1594: ** IRQ peripheral usb0008 tx0000 rx0002
> musb_stage0_irq 462: <== Power=f0, DevCtl=99, int_usb=0x8
> musb_g_rx 765: <== ep1out, rxcsr 0003 (dma) dec244c0
> dma_channel_program 165: ep1-Rx pkt_sz 512, dma_addr 0x9ecc7002 length
> 341, mode 0
> configure_channel 130: dec57068, pkt_sz 512, addr 0x9ecc7002, len 341, mode 0
> dma_controller_irq 302: ch dec57068, 0x9ecc7002 -> 0x9ecc7155 (339 /
> 341) => reconfig 0
> ......

BTW:  No such issue in omap3530 of beagle B5, but find it in DM3730 of
beagle xM with the same musb driver and kernel.


-- 
Lei Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Gadiyar]

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

Any other ideas?

- Anand

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

[Ming Lei]

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

thanks,
-- 
Lei Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ming Lei]

Hello,

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
>
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Gadiyar]

On 10/28/2010 11:36 AM, Ming Lei wrote:
> Another question, musb_read_fifo and musb_write_fifo need to be fixed to
> use 32bit operation only alike am35x?

Nope - that limitation is only in certain AM35x SoCs. OMAP36xx/37xx are 
not affected.

- Anand

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Gadiyar]

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

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

[Ming Lei]

2010/10/31 Anand Gadiyar <gadiyar@ti.com>:
> On 10/27/2010 11:27 AM, Ming Lei wrote:

>> 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).

Seems DMA code should not be rewritten, only a DMA version
of musb_write_fifo and musb_read_fifo need to be implemented as
omap dependent code just like Blackfin,  right?

>
> I've posted a patch implementing the quick fix. Let me know if it solves the
> problem with g_ether.

Yes, I have tested your patch about g_ether on beagle xM, and it does fix
the DMA issue for unaligned buffer address.

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


-- 
Lei Ming