There is a delay between each SPI transfer when using AGX-orin-64g

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:

bash

sudo ./spidev_test -D /dev/spidev1.0 -s 12000000 -S 32 -I 1000

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?


Hi,
On Jetson platforms, we support using peripherals like CAN, SPI, I2C, UART… etc. for the user.
For CAN usage:
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/ControllerAreaNetworkCan.html
For the connection of peripheral on the devkit, please refer to expansion-headers guide and carrier board specification:
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/ConfiguringTheJetsonExpansionHeaders.html

For pin configuration, please refer to pinmux spreadsheet:
https://developer.nvidia.com/embedded/secure/jetson/agx_orin/jetson_agx_orin_pinmux_config_template.xlsm

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.

Thanks!

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?

Hi zhangw66,

Could you apply the patch from Jetson orin nano SPI Speed not changing - #9 by KevinFFF for SPI driver to check if it could help for your case?

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