Inconsistent SPI latencies

[asdaposdi]

Hi,

I am running Linux (Yocto) on the Variscite VAR-SOM-MX8M-PLUS (iMX8MP).

I need to stream large amounts of data quickly over SPI, but the time each transfer takes is very inconsistent. In general, I see:

• a large delay when starting the transfer before the first clock edge (up to hundreds of microseconds),
• a large delay after the last clock edge before returning from the transfer (up to hundreds of microseconds), and
• an inconsistent delay between bursts in the same transfer.

In practice, I see that a 2048 byte transfer at 10MHz can take between 2 and 8 ms, where it should take only 8*2048/10MHz = ~1.6ms.

I also occasionally get -ETIMEDOUT, which seems to be the DMA transfer timing out.

I found this thread with similar problems to mine, which provided several solutions that have made some improvements, including isolating a CPU for SPI work.

Am I hitting a hardware limitation? Would moving my SPI interfacing to the Cortex-M core fix this?

Thanks

[Dhruvit]

Hi @asdaposdi,

I hope you are doing well.

Could you please share the waveform, and device tree node for further debugging?

Please mention how you are testing it in userspace

The delay between two SPI bursts can be caused by dma limitations.

It seems to be expected behavior.

Yes, Moving SPI interfacing to the Cortex-M core can show improvements.

Thanks & Regards,
Dhruvit Vasavada

[asdaposdi]

Hi,

Here's the device tree node:

#include "imx8mp.dtsi"
&ecspi2 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ecspi2>;
    status = "okay";
};

I'm running a kernel module (calling spi_sync_transfer), but I've tested with spidev_test by sending data and measuring on a scope.

Each attachment is a single 2048 byte transfer at 10MHz, including a fast example and a slow example with increasing zoom. I'm just showing the clock so you can see how long the transfer takes.

In fast.png, the clock is continuous with small delays between each byte.

In slow.png, there are large delays every 32 bytes and significant delays between each byte.

Is this the DMA limitation? If so, would the Cortex-M not have the same issue?

Thanks

[Dhruvit]

Hi @asdaposdi,

I hope you are doing well.

can you please share the waveform of the CS pin with SCLK.?

Please also mention the kernel version used and chip select information & pinctl.

In DMA mode burst length is limited to word size (32 bits.)

Thanks & Regards,
Dhruvit Vasavada