SPI-IMX.c data handling time [ iMX6 + Apalis ]

Technical Support
, , , ,
1

Hi Toradex Team ,

In one of our application the customer requirement is to get the SPI ADC samples within 20uS.
I tried with iMX6 + ECSPI + kernel ( spi_read function ) but we got time approx 110uS , much more than the value we calculated .

Hence can team please help us with :-

  1. Does toradex team have any pointers w.r.t scratch/ test spi controller driver with which the spi-read activity takes less time ?

  2. The SPI controller driver looks like is using imx51 driver for spi core , as there is no driver binding for "ffsl,imx6q-ecspi " . So could you please confirm that the “imx51-ecspi” is proper binded driver code?

  3. There was an test protocol interface of “spidev” in kernel .
    Will using this improve the performance ? .
    Because in our kernel driver code (probe function ) we are calling simply an spi-read function .
    ( The idea was to test with the minimal overhead & hence no involvement of application space code for initial round of testing )

  4. I tried to disable the driver & directly access the escpi register’s but the system enters in panic mode when we try to configure the CLOCK register. Idea was to an scratch SPI read without DMA engine
    Does Toradex has any similar test code .

2

Hi Team ,
Any Input which Toradex team can share on this.

3

Hi

In one of our application the customer requirement is to get the SPI ADC samples within 20uS. I tried with iMX6 + ECSPI + kernel ( spi_read function ) but we got time approx 110uS , much more than the value we calculated .

I doubt that reaching latencies in the range of <100μS will be an easy task, if not impossible.
Please also refer to the Real-Time Linux article.

We at Toradex have no experience in removing ‘avoidable’ delay in the SPI stack.

Yes, the iMX 6 uses the same driver / driver variant as the i.MX 51 for eSPI.

spidev is an interface through the dev filesytem to access the SPI devices from userspace. (/dev/spidevX.Y nodes). Using SPI from userspace will likely add additional asynchronous calls and thus adding additional delay.

I guess your best bet will be to abandon the kernels spi subsystem and write a dedicated driver which combines the handling of the eSPI HW and the external connected SPI device.

The probably fastest AD read is a driver which disables interrupts, starts an AD conversion, busy waits for completion, reads the results and reenables interrupts to get the fastest possible access at the price of a non-portable non-generic software design and worse latency for all other contenders for the CPU.

Max

4

Dear Max ,
Thanks for valuable feedback …

  1. Going through the code , i could sense that the lower driver has DMA working to help SPI . Just in any case does toradex has the code without DMA.

We are working for the option “4” , but the clock subsystem is creating an problem which i am trying now .

Thanks,
Ashish Kumar Mishra.

5

Hi

drivers/spi/spi-imx.c can do DMA or PIO mode.

With DMA channels assigned in the device-tree it will use DMA if the requested transfer does not fit in the hardware FIFO, otherwise it will use PIO mode.

You can disable DMA completely by changing the device-tree.
e.g. overwrite the default dma-names property so that the driver does not have an assigned DMA channel.

diff --git a/arch/arm/boot/dts/imx6qdl-apalis-eval.dtsi b/arch/arm/boot/dts/imx6qdl-apalis-eval.dtsi
index 72033ac..577ef07 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis-eval.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis-eval.dtsi
@@ -115,6 +115,8 @@
 &ecspi1 {
        status = "okay";
 
+       dma-names = "", "";
+
        spidev0: spidev@1 {
                compatible = "toradex,evalspi";
                reg = <0>;

Max

6

Dear Max ,
w.r.t fifo we are transmitting well within hardware fifo.
Tested with 2, 4, 8 & 18 bytes…
Also w.r.t Imx6/linux: Large and inconsistent latency when issuing an irq triggered spi read - Technical Support - Toradex Community having “200us worst case with stress tests I did using our Apalis iMX6 with our 3.14.28 kernel patched with PREEMPT_RT) - again this is still not a guarantee.”
may not be that helpful . But still if required we will test it once.

Thanks for reply as they helped us to ensure we are not doing any thing wrong for our initial skeleton driver.