i.MX ProcessorsのトピックRe: iMX8MP SPI timing issues

iMX8MP SPI timing issues

andrej_valek — Thu, 09 Oct 2025 13:32:59 GMT

Dear community!

I have some questions about the SPI behavior on imx8mp... .

MASTER

As I'm using the IMX Linux Kernel 6.6.36 with SPI Master settings.

pinctrl_ecspi1: ecspi1grp { fsl,pins = <MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x82>, <MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x82>, <MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x82>, <MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09 0x82>; }; &ecspi1 { #address-cells = <1>; #size-cells = <0>; cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi1>; status = "okay"; spidev0: board@0 { compatible = "rohm,dh2228fv"; reg = <0>; spi-max-frequency = <20000000>; }; };

so fully HW SPI should be used with chip-select as well.

I wanted to send some bytes from this peripheral, so I used spidev_test binary for those purposes:

spidev_test -D /dev/spidev3.0 -v -s 20000000 -b 8 -p "\x11\x22\x33"

It should send 3 bytes from master at 20MHz which is working fine, from data point of view, but not the timing. If I send more bytes, the delay between last clock and deactivation the chipselect is in range of microseconds. Sometimes it's ~4us, sometimes ~500us, so it's really nondeterministic.

So it's basically unusable if you imagine, that I wanted to use 512B transfer at 120Hz, which is ~8.33ms and the delay will be ~1ms.

I was looking into driver and didn't find any place where the delay or timeout should happens. https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/drivers/spi/spi-imx.c or https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/drivers/spi/spi.c should have the delays set to 0 while is not set. How to really set the value to minimum or make it deterministic at least. Is it done by design, or there is some king of bug?

Next problem is with multi spi_ioc_transfers. If you send multiple transfers, they are "scheduled" not immediately, but sometimes there is some kind of delay between them.

Is it done by scheduler, or where/how this happen?

SLAVE

Now we look at the slave part.

pinctrl_ecspi2: ecspi2grp { fsl,pins = <MX8MP_IOMUXC_SD2_DATA3__ECSPI2_MISO 0x1C0>, <MX8MP_IOMUXC_ECSPI2_MOSI__ECSPI2_MOSI 0x1C0>, <MX8MP_IOMUXC_ECSPI2_SCLK__ECSPI2_SCLK 0x1C0>, <MX8MP_IOMUXC_SD2_DATA2__ECSPI2_SS0 0x1C0>; }; &ecspi2 { #address-cells = <0>; #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi2>; spi-slave; status = "okay"; };

I wanted to use the slave in a way, where the number of received bytes is not known. I wanted to use a variant which will be relying on CS. I have to probably create an own driver with ring-buffer and inform a user-space once the data have been received. Is it even possible to wrap this driver?

Many thanks for any kind of advice.

Andy

Re: iMX8MP SPI timing issues

AldoG — Fri, 10 Oct 2025 21:28:34 GMT

Hello,

This could be related to the scheduling, is the ecspi the only thing running when you are running your test?

Also, regarding creating your own driver this could be possible, for this I would recommend to reach our pro support they would be able to help you on that:

https://contact.nxp.com/new-prof-svcs-sw-tech

Best regards/Saludos,
Aldo.

Re: iMX8MP SPI timing issues

andrej_valek — Mon, 13 Oct 2025 14:49:00 GMT

Hello,

First, I would like to thanks for the replays, but I have an another questions then.

This could be related to the scheduling, is the ecspi the only thing running when you are running your test?

Yes, nothing else, just a spidev_test utility was running on the device. Is there a way to see the scheduling, or?

I made some more measurements...

spidev_test -D /dev/spidev3.0 -b 8 -s 20000000 -I 10000 -S 4096 spi mode: 0x0 bits per word: 8 max speed: 20000000 Hz (20000 kHz) rate: tx 9660.0kbps, rx 9660.0kbps rate: tx 10918.3kbps, rx 10918.3kbps rate: tx 10898.6kbps, rx 10898.6kbps rate: tx 10905.2kbps, rx 10905.2kbps rate: tx 10911.7kbps, rx 10911.7kbps rate: tx 10918.3kbps, rx 10918.3kbps total: tx 40000.0KB, rx 40000.0KB

As you can see, that clock is set to 20MHz, but the real speed is about ~10Mbps. So I change the clock to 50MHz.

spidev_test -D /dev/spidev3.0 -b 8 -s 50000000 -I 10000 -S 4096 spi mode: 0x40 bits per word: 8 max speed: 50000000 Hz (50000 kHz) rate: tx 13349.7kbps, rx 13349.7kbps rate: tx 13382.5kbps, rx 13382.5kbps rate: tx 13369.3kbps, rx 13369.3kbps rate: tx 13395.6kbps, rx 13395.6kbps total: tx 40000.0KB, rx 40000.0KB

and in this case the speed was ~13Mbps.

I'm expecting the speed about 20 or 50Mbps for these clocks. If we look at the DTB:

ecspi1: spi@30820000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,imx8mp-ecspi", "fsl,imx6ul-ecspi"; reg = <0x30820000 0x10000>; interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clk IMX8MP_CLK_ECSPI1_ROOT>, <&clk IMX8MP_CLK_ECSPI1_ROOT>; clock-names = "ipg", "per"; assigned-clock-rates = <80000000>; assigned-clocks = <&clk IMX8MP_CLK_ECSPI1>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_800M>;

I don't see some kind of limitation because of clock. So what's the real bottleneck here? Is there some kind of ECSPI HW limitation, or?

I would recommend to reach our pro support they would be able to help you on that

Ok, good to know, that there is a way to get better support. Maybe I will use it in the future... .

BR,

Andy