The same test on a Xavier NX (older version of jetpack with Linux 4.9) can do it a lot faster
How can we reduce the 300us delay?
We are using the nvidia devkit device tree w/ no changes to the default SPI nodes in the device trees for both the xavier and orin. We are not setting any delays intentionally
Hi akhil.veeraghanta,
Are you using the devkit or custom board for Orin NX and Xavier NX respectively?
Since they are using the different kernel release, could you verify the status for Xavier NX with K5.10?
What’s your SPI device used in your test? Or it could also be reproduced in the loopback test?
What frequency do you configure for SPI?
They are both on the devkit
There is no spidevice, we are just transmitting and measure chipselect and clock. We configure SPI at 20MHZ
Could you verify the status for Xavier NX with the latest JP5.1.2 - R35.4.1which is using K5.10?
so that we could clarify if the issue is coming from the platform or the kernel release.
I can’t use 35.4.1 yet, but there don’t seem to be any SPI changes at initial glance
polling mode seems to crash in 35.3 as well
[ 69.825998] spi-tegra114 3210000.spi: interrupt raised in polling mode
[ 69.826258] spi-tegra114 3210000.spi: interrupt raised in polling mode
[ 69.826505] spi-tegra114 3210000.spi: interrupt raised in polling mode
[ 69.826775] spi-tegra114 3210000.spi: interrupt raised in polling mode
[ 69.892561] CPU:0, Error: cbb-fabric@0x13a00000, irq=25
[ 69.892710] **************************************
[ 69.892852] CPU:0, Error:cbb-fabric, Errmon:2
[ 69.892982] Error Code : TIMEOUT_ERR
[ 69.893090] Overflow : Multiple TIMEOUT_ERR
[ 69.893277] Error Code : TIMEOUT_ERR
[ 69.893398] MASTER_ID : CCPLEX
[ 69.893494] Address : 0x3210014
[ 69.893602] Cache : 0x1 -- Bufferable
[ 69.893716] Protection : 0x2 -- Unprivileged, Non-Secure, Data Access
[ 69.893904] Access_Type : Read
[ 69.893997] Access_ID : 0x10
[ 69.893999] Fabric : cbb-fabric
[ 69.894203] Slave_Id : 0x3b
[ 69.894288] Burst_length : 0x0
[ 69.894382] Burst_type : 0x1
[ 69.894471] Beat_size : 0x2
[ 69.894552] VQC : 0x0
[ 69.894712] GRPSEC : 0x7e
[ 69.895173] FALCONSEC : 0x0
[ 69.895633] **************************************
[ 69.896373] ------------[ cut here ]------------
We blindly copied the spi-tegra114.c file from 4.9 into 5.10 and that brought the timing to be a lot better on the orin.
From your result, it seems relating to the driver in these two kernel release.
Does you SPI work as expected with K5.10 after you use the SPI driver from K4.9?
Yes it does, can this be fixed by NVIDIA in 5.10?
We don’t want to be limited in future upgrades when some of the API in 4.9 is deprecated
It is the difference between the kernel release.
We won’t reverse the kernel driver back to old release.
I’m not quite sure if the issue is caused from some new feature in K5.10 so that the performance worse than K4.9.
Yeah I was hoping you guys can fix the newer release given that its reasily reproducable
Okay, l’ll check this issue with internal and update to you once there’s any result.
