SPI_IOC_MESSAGE ioctl for SPI extremely slow

Do you enable HW based CS in device tree?

Is your current issue about the performance?

Have you also tried using spidev_test tool?

Is the issue specific to your SPI device? Or you would also hit the performance issue if you perform the SPI loopback test through shorting MISO/MOSI?

I have also been stuck with long and erratic SPI latency in JP6 (I haven’t tried different Jetpacks)
If I just send SPI packets in an infinite loop with no delays and look at the SPI lines with an Oscilloscope,
I find that sometimes the delay between packets is only a few hundred us but can be as high as 20ms or more.
I get an average of about 2500 packets per second (it varies quite widely) and doesn’t seem to be affected by the SPI frequency. Although I have only tried 5, 10 and 20MHz (Less than 5MHz wouldn’t work for my application)

The performance is bad because there are long delays between packets for no reason I can discern. I have not tinkered much with changing the clock frequency.

Loopback would not change anything. Unlike I2C, I’m pretty sure SPI doesn’t have any concept of slave device throttling or clock stretching. In other words, this cannot be a function of the slave device.

I found this discussion:

Someone is saying that the “spidev” driver is not supposed to be used for normal application. It’s for prototyping only. So can someone with Nvidia tell us what is the “real” SPI driver we should be using instead?

For interest sake, I have previously used spidev on an old Raspberry PI 3B to communicate with an ADC. I was easily able to get 8k samples/second which required polling the data ready pin and then retrieving the samples via SPI when the data ready pin went low (meaning I was able to keep up with the ADC and didn’t miss any samples). On the Jetson, I can get about 2k samples/second if I don’t even try to poll the data ready pin and just get samples as fast as possible. Even then, the timing is very erratic so the samples are useless.

Many people is frustrated, in one hand is true that the spidev creators state clearly that “this is not for production purposes” but in other hand spidev is extremely popular, many people just need some ioctls to be able to get data from some peripheral in a simple, generic way.
To make things more interesting, depending on the underlying hardware or driver version, results are not comparable, I was able to get over 20k small transfers/second on the old Jetson Nano back in the day, now in the Orins I am getting 3k/second.
Problem is, spidev is meant to work in many different architectures so the maintainers can’t optimize for any specific ones, that’s a thing.
An alternative could be for manufacturers to provide their own versions of spidev (call it whatever) optimized for their own architectures, that would be good.

Thanks @Rubberazer to point out the spidev_test.
We do have our spidev_test binary for Jetson device.
Please verify with the following binary with JP5.1.3 to check if it could help for SPI packet delay issue.
spidev_test (64.1 KB)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.