imx6q: spi - sdma speed to 30Mhz

[angelo_d]

Hi all,

working actually on a quite old 4.1.15 kernel based on mainline.

Working with ecspi, master, at 10Mhz i can properly receive preconfigured 16words x 16bits bursts using dma. sdma fw is 03.03

Going up to 30Mhz, in the rx buffer i see groups of 8words x 16bits (even if the burst  is 16x16) repeated the same as the previous 8x16 block, so that one 8x16 group is lost.

Watermark seems set as half of the fifo size, 32 words.

I also checked the sanity of the bitstream by oscilloscope, the bitstream is sane, good bits shape, and i clearly see 16x16 bursts and can confirm second 8x16 word block is lost from imx6q.

Any help is welcome.

[weidong_sun]

Hi,

    It is recommended that you connect MOSI and MISO signals together, and then test the results of SPI data receiving and sending at 30MHz.

Have a nice day!

B.R,

Weidong

[angelo_d]

Sorry, not clear. Ok for the method, but datasheet says i cannot receive at 30Mhz. 25 max for fast group, 18Mhz for slow. Can you confirm this ?

[ceggers1]

Hi spectrum,

I have no access to the revision history of the SDMA firmware files, but you may try the latest version from here:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma?h=master

Probably your problem is somehow related to ERR009165 (https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf), but in my opinion it is more likely that the RX FIFO is overrun in some way. Usually, SPI transfers are "triggered" by writing into the tx (FIFO) register.

Depending on the SDMA script, the process of copying 64 words into the TX FIFO may be uninterruptible. I can imagine 2 situations which would overflow the RX FIFO:

1. The RX FIFO is not completely empty when starting pumping data into the TX FIFO.

2. Another TX transfer is started before any data has been read from the RX FIFO at all. This can probably happen because the TX FIFO signals "empty" a little bit early than the RX FIFO signals "full".

Unfortunately I cannot tell you a ready-made solution for this problem. If possible, you should test with the latest kernel and SDMA firmware. As a next step, I would suggest inserting some extra checks into the SDMA scripts in order to determine whether the RX FIFO is overrun at any time.

regards
Christian

[angelo_d]

Hi Christian,

well, i did some further investigations:

i should get this binary pattern from the slave device

0000 0000 0000 0000
0000 0000 0000 0001
0000 0000 0000 0002
...

i get it properly at 10Mhz but at 30Mhz i get:

0000 0000 0000 0000
0000 0000 0000 0000 <- duplicated 8 byte entry
0000 0000 0000 0001
0000 0000 0000 0001 <- duplicated 8 byte entry
.... and so on

1 - oscilloscope show the proper original right data stream is on the wire
2 - a recent 5.9 kernel, mainline, seems working also without using sdma firmware, but even loading last 3.5 fw, nothing changes, same issue
3 - setting to "pio" mode, i still have the same exact issue, so dma seem not involved, but the increased speed only seems causing the issue
4 - reading a random pattern. instead of the above sequence,
seems the transfer works properly, no 8-byte blocks duplicated,
and seems inline with data on wire, same sdma and pio mode.

Thanks a lot for now, inspecting the errata.

angelo

[ceggers1]

Hi Angelo,

> 2 - a recent 5.9 kernel, mainline, seems working also without using
> sdma firmware, but even loading last 3.5 fw, nothing changes, same issue
many SDMA routines are stored in the internal ROM. When a RAM firmware is loaded, some ROM routines are replaced (by using a jump table in RAM) and some routines (which do not exist in the ROM) are added. In case of eCSPI, the RAM firmware contains an updated version. The RAM version is required due to the errata in mentioned.

> 3 - setting to "pio" mode, i still have the same exact issue, so dma seem not involved,
> but the increased speed only seems causing the issue
For me it sounds unlikely to get the same behavior with/without SDMA. Please check /proc/interrupts to ensure, that SDMA is really in use (in PIO mode, you'll get more SPI and less SDMA interrupts as in DMA mode).

What driver do you use for accessing you SPI device (eeprom, flash, spidev, ...)? In some cases, such errors can also be caused by missing cache alignment/invalidation.

regards
Christian

[angelo_d]

Hi Christian,

thansk a lot for following, will try sdma 3.4 and 3.5 (using 3.3 now).

But, my fear now is:

If for Cycle Time-Read is mean spi "good" readings, so 55ns should allow 18Mhz max.  

I initially intended the "read" as reading clock, but realizing later the time table is for master mode ...

Also, seems the only reliable RX cycle i can get is at 11Mhz, moving to 12 i start to see the issue. And this is quite terrible, 18 should be the limit. Looking around to confirm this.