UP xtreme SPI speed problem

i have upboard with RT-patch is being used for SPI communication. (more than 6MHz)
(ubuntu16.04, kernel 4.4.86)
link : https://github.com/QiayuanLiao/Ubuntu-RT-UP-Board
recently, I needed a faster operation, so I bought up extreme.
(ubuntu18.04, kernel Linux upxtreme-UP-WHL01 5.0.0-1-generic)
link : https://wiki.up-community.org/Ubuntu_18.04#Install_Ubuntu_kernel_5.0.0_from_PPA_on_Ubuntu_18.04
i expected batter than UPboard. but I can currently communicate with SPI at a speed of 2MHz.
When the communication speed is increased(more than 2MHz), data corruption or shift occur.
I tried applying lowlatency as well, but it failed(same problem).
The development board(STM32F4) is directly connected on the 40pin header, and there is no communication problem in the upboard.
setting value
data length is more than 100byte.
spi mode : SPI_MODE_0
bits per word : 8bits
SPI_IOC_RD_LSB_FIRST : 0x01
Comments
Please check out this topic for more info: https://forum.up-community.org/discussion/comment/11316
======================================================================================================
======================================================================================================
let me know any other link?
there is a kernel 5.4: https://packages.ubuntu.com/bionic/linux-generic-hwe-18.04-edge
but it doesn't include our patches for pincontrol, we are currently working on it and we expect to have it released in early Q4
i use low latency kernel now (Linux upx-UP-WHL01 5.0.8 #3 SMP PREEMPT Tue Aug 25 17:56:31 KST 2020 x86_64 x86_64 x86_64 GNU/Linux )
When viewed through an oscilloscope, I found that the clock stopped in the middle at a setting of 13MHz or higher.
Because of this, communication errors(shift, change, loss) are occurring, and there is a limit to speeding up the communication speed.
Will this problem be solved in the currently produced kernel? (kernel 5.4)
I have to send and receive more than 150 bytes of data per cycle with a clock of more than 20MHz and a cycle of less than 500us.
When looking at the time between the point where the CS pin goes low and the point where the clock starts, it can be seen that the UP board takes 28us time at 12MHz clock and the UP xtreme takes 0.48us time at the same clock.
It was confirmed that the time of UP board was similar regardless of clock, but UP xtreme decreased to 0.25us.
If a program is created using CS interrupt, it can be seen that there is a problem in data catching due to a short time of 0.48us in UP xtreme.
To fix this, I am wondering if there is a way to adjust the time until the clock starts after the CS pin goes low.
Hello @jhp
The SPI performance on UP Series are affected mainly by the Intel SPI driver implementation.
As mentioned in previous posts, the newer Kernels from 5.4 onward, are improving considerably the performance for UP Xtreme, resolving previously highlighted issues.
At this moment we have tested Speed on UP and UP Xtreme up to 12 Mhz with Kernel 5.4, so we cannot tell right now if the SPI driver on 5.4 allows to reach the 20Mhz requirement. We will extend our test cases to increase the test speed for the SPI interfaces before releasing the new Kernel based on 5.4.
As mentioned above, that depends on the Intel SPI driver implementation and internals of the SPI controller, so the best way would be to either file a bug or report the issue on the Intel communities where their kernel developer may help to address this specific issue.
Can you give me a specific release schedule for kernel 5.4?
Kernel 5.4 upgrade work is ongoing.
The release is delayed due some issues encountered during the upgrade on the driver specific for the UP Board (first generation UP based on Cherry Trail).
We expect to release the kernel as soon as the issue is solved and validation completed, hopefully just few weeks from now.
5.4 The kernel update is late, please let me know when it will be released.
Are there any known reason(s) for this high 28us delay on the up board CS ?