Two parallel SPI reader threads instability

[jangodborg]

We have a C++ application on DART-6UL Linux, collecting data from two eCSPI SPI ports from camera sensors, one on each port. We Read from the SPI ports only, there a no write operations.There is a separate thread (running real-time priority (SCHED_RR)) for the data collection from each spi port.

The Linux kernel has been built and tested using both MORTY and PYRO Linux's.

When reading only one port it runs great, and the application can retrieve all data at the rate delivered from the sensor (ca 8 frames per second; each frame is ca 40Kb).

When running two instances in parallel for the ports the performance drops significantly.

We have tested using both the read() systemcall and ioctrl() (with the SPI_IOC_MESSAGE(1) macro) in the reader thread, however the performance is identical.

Does anyone have suggestions to these issues:

- can any system/kernel tuning be performed to optimize to the performance
- can you provide sample programs demonstrating how to obtain our required performance
- Are anyone experiencing similar SPI problems ?

Thanks in advance.

[jangodborg]

Can you possibly give some information about how to tune our system to improve the performance of the two SPI threads, as to obtain an improved performance of the spi reader process.

We have experimented with bus speeds without good results. Please state possible other alternatives we can try (kernel parameter tuning or ? ).

We really need some expert advice.

Thanks you.
Jan Godborg.

[mtx512]

Unfortunately there isn't a simple answer to where the bottleneck could be, however below are some suggestions base on our experience:

1. Verify the spi kernel driver is using DMA for transfers.

2. Run SPI at the max clock speed the camera supports.

3. If you know the max SPI clock speed of the camera and data packet length you should be able to roughly calculate the expected throughput per second. This should give you a rough estimation of what should be possible with 2 cameras attached. 

4. If possible you should try using one eCSPI port plus the SS pins to multiplex between the two camera. This should reduce context switching of kernel driver instances.

5. From the application side you should reuse a pool of buffers and not allocate on demand.

[igorpadykov]

Hi Jan

for improving performance may be recommended to apply to NXP Professional Services:

NXP Professional Services|NXP 

Best regards
igor

[igorpadykov]

Hi jan

one can try with nxp linux releases described on

https://www.nxp.com/support/developer-resources/run-time-software/i.mx-developer-resources/i.mx-6ser...

Usually performance drop happens due to internal bus limitation, so one can consider to

descrease bus loading (usage) from other modules.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jangodborg]

Thanks,

Can you be a bit more specific as to which bus it can be? We would like to know what exactly is the bottleneck.

Even changing the design to another Soc may not solve the problem if it has the same bottleneck (and it is not a convenient option in our project now).

Is there any option to optimize, e.g. increasing the clock on that bus?

Thanks Jan

[igorpadykov]

Bus connections are quite complex and similar to i.MX6DQ described
on Figure 45-1. NIC-301 Bus System i.MX6DQ Reference Manual
http://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf
and I am afraid there is no way to find which bus exactly is bottleneck
(there are no tools to find it), just as estimation for measuring bus loading
one can try MMDC Profiling tool
https://community.nxp.com/message/873372 
One can narrow down issue with running test without linux, using FreeRTOS :
Board Support Packages (7)
SDK2.2_iMX6UL_WIN(REV SDK2.2)
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-processors/i.mx-6-pr...

Best regards
igor