Re: [PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API

[Tony Lindgren]

* Tony Lindgren <tony@xxxxxxxxxxx> [170504 12:43]:
> Hi,
> 
> * Peter Ujfalusi <peter.ujfalusi@xxxxxx> [170503 04:00]:
> > With the port_window support in DMAengine and the sDMA driver we can
> > convert the driver to DMAengine.
> 
> Actually looks like this patch still has some issues.. Pinging
> the n8x0 with for example ping -s1 causes things to stop working.

Sorry it's actually ping -s2048, not -s1. Here's what happens
on n8x0 with first ping -s2048 with 4/4 applied:

musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000010
g_ether gadget: invalid EEM CRC
g_ether gadget: invalid EEM CRC
musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x86803842 len: 512(512) packet_sz: 512(512)
musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from 0x02000620 to 0x86803842
musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
musb-hdrc musb-hdrc.1.auto: DMA remaining 448/512
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 000001c0
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000008
musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x869fdc02 len: 512(512) packet_sz: 512(512)
musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from 0x02000620 to 0x869fdc02
musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
musb-hdrc musb-hdrc.1.auto: DMA remaining 448/512
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 000001c0
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000008
musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x869fc642 len: 512(512) packet_sz: 512(512)
musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from 0x02000620 to 0x869fc642
musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
musb-hdrc musb-hdrc.1.auto: Corrupt rx XFR_SIZE: 0x7ffffec0
musb-hdrc musb-hdrc.1.auto: DMA remaining 0/512
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 7ffffec0
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000008
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 00000010
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 7ffffcf0

It seems the hardware dmareq line is not triggering anything
above?

Also with just ping with no size specified, it seems every other
packet is missed or DMA interrupts are not properly triggering
as I'm getting these:

g_ether gadget: invalid EEM CRC

> This is when using only with the async gpmc access as the sync
> gpmc access seems to have a regression not related to this series.
> I'll try to track down that sync gpmc issue as that most likely
> hints to something being wrong in the gpmc code in general.

And this sync gpmc issue seems to be timing related. Setting
DEBUG in tusb6010_omap.c makes it happen easily while without
it it's much harder to trigger. So probably some kind of issue
with GPMC sync timings.

I also found one other issue that might need fixing depending
on the bootloader version, see below.

Regards,

Tony

8< -----------------