I am using L4T version: R36 (release), REVISION: 3.0. When using the SPI controller, I noticed a certain delay between each transfer. I am using the default spidev driver provided by the kernel, and the test program is also the default one in the kernel, located at tools/spi/spidev_test.c. The test command is as follows:
I added GPIO toggle operations at the entry and exit of the tegra_spi_transfer_one_message function in the file drivers/spi/spi-tegra114.c. I found that this function takes around 52us to execute, while the actual data transfer only took 22us. So, where is the remaining 30us spent?
By default, the configuration is used for the devkit. If you are using the custom carrier board, please configure it according to your custom board design.
There are also several examples which have been verified from us, please check https://elinux.org/Jetson/L4T/peripheral/
Please share the full dmesg and device tree for us to check your status in detail.
We are using the official development kit and firmware images. The issue was first noticed when we used an SPI-to-CAN chip. During usage, we found that the CAN frame rate was relatively low. At the same time, we are also using the native CAN module of the AGX Orin. The performance of the SPI-to-CAN chip is only about 70-80% of the native CAN performance. After some analysis, we believe that the performance degradation is caused by the SPI transfer. Therefore, we would like to inquire about the issue mentioned at the beginning: why did the actual data transfer take 22us, but the total overhead of the function increased by 30us?