cyclictest versus custom SPI based system

cyclictest versus custom SPI based system

[Julio Cruz Barroso]

Hi,
 
I’m using a linux-wandboard-rt 3.14.28, with a max latency of 114us [1].
 
I would like include an IIO driver to acquire data from a SPI device @ 1Hz.
 
After disable some modules (as suggested two months ago by Mat and tglx [2]) the acquisition is more stable, however it still losing data.
 
Based on a scope and a couple of GPIO, I could find that the SPI handler is not firing sometimes.
 
I don’t understand why the max latency (with cyclictest is 114us) and the SPI handler @1ms is failing with delays of 3 to 5ms.
 
There is a way to force the SPI handler over all others kernel process?
This could be related with the priority of the SPI (spi0)? In this case the thread spi0 has PRI of 20 with a nice of 0 [3].
Do you suggest to continuing digging to find the cause in other modules?
 
Thanks
Julio
 
-----
[1] cyclictest result
cyclictest -t1 -p 80 -n -i 1000 -l 100000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.11 0.25 0.14 1/94 549
T: 0 (  548) P:80 I:1000 C: 100000 Min:     10 Act:   15 Avg:   15 Max:     114
 
-----
[2] [2015-09-26 9:38:02] Long max latencies on Wandbaord / Freescale i.MX6
 
-----
[3] htop and system modules: http://postimg.org/image/jrvcw5v59/--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cyclictest versus custom SPI based system

[Daniel Bristot de Oliveira]

On 01/13/2016 03:06 PM, Julio Cruz Barroso wrote:
> This could be related with the priority of the SPI (spi0)?
In this case the thread spi0 has PRI of 20 with a nice of 0 [3].

Hi Julio,

You must run SPI's IRQ thread on a real-time policy:priority. For
instance, chrt -p -f 50 $(pidof spi0).

I used work with an ARM processor running kernel-rt on both master and
slave side of a SPI bus, and it worked fine when using threaded IRQ.

If you continue facing long latencies, you can use the (big hammer)
IRQF_NO_THREAD flag on SPI's IRQ handler registry. This will force the
SPI handler to run as a traditional - non threaded - IRQ handler.

I did it on a very special case of a 200MHz ARM running kernel-rt on the
slave side of a SPI bus. As it was on the slave side, any additional
overhead (like the scheduling overhead of the threaded handler) was
impacting on master's side performance, that was a very busy DSP (ADBF
@500Mhz). It worked fine! But the SPI's IRQ was the "highest priority"
task, on a very controlled env.

-- Daniel

RE: cyclictest versus custom SPI based system

[Julio Cruz Barroso]

Hi Daniel,

Thanks for your suggestion. 

I changed the policy:priority as you suggested and the system is stable now!! I will prepare an application to measure the latency with some loads during long periods (but this is another thing).

For reference, in my case (iMX6), the priority adjustment was done at spi.c (master->rt). A patch was suggested to implement this by device tree but other opinion said that this sound like a Linux specific feature/implementation [4]. Anyways, this is another issue.

Thanks,

Julio

[4] Patch to implement SPI RT in device tree: http://www.spinics.net/lists/arm-kernel/msg348713.html


-----Original Message-----
From: Daniel Bristot de Oliveira [mailto:daniel@bristot.me] 
Sent: Thursday, January 14, 2016 2:37 AM
To: Julio Cruz Barroso <julio.cruz@smartmatic.com>; linux-rt-users@vger.kernel.org
Subject: Re: cyclictest versus custom SPI based system



On 01/13/2016 03:06 PM, Julio Cruz Barroso wrote:
> This could be related with the priority of the SPI (spi0)?
In this case the thread spi0 has PRI of 20 with a nice of 0 [3].

Hi Julio,

You must run SPI's IRQ thread on a real-time policy:priority. For instance, chrt -p -f 50 $(pidof spi0).

I used work with an ARM processor running kernel-rt on both master and slave side of a SPI bus, and it worked fine when using threaded IRQ.

If you continue facing long latencies, you can use the (big hammer) IRQF_NO_THREAD flag on SPI's IRQ handler registry. This will force the SPI handler to run as a traditional - non threaded - IRQ handler.

I did it on a very special case of a 200MHz ARM running kernel-rt on the slave side of a SPI bus. As it was on the slave side, any additional overhead (like the scheduling overhead of the threaded handler) was impacting on master's side performance, that was a very busy DSP (ADBF @500Mhz). It worked fine! But the SPI's IRQ was the "highest priority"
task, on a very controlled env.

-- Daniel

Re: cyclictest versus custom SPI based system

[Grygorii Strashko]

Hi Julio,
On 01/14/2016 10:11 AM, Julio Cruz Barroso wrote:
> 
> I changed the policy:priority as you suggested and the system is stable now!! I will prepare
 an application to measure the latency with some loads during long periods (but this is another thing).
> 
> For reference, in my case (iMX6), the priority adjustment was done at spi.c (master->rt). A patch 
was suggested to implement this by device tree but other opinion said that this sound like a Linux
 specific feature/implementation [4]. Anyways, this is another issue.
> 

Just curios, is it possible for you to achieve the same results from User space using chrt/taskset utils?
(without Kernel modification).

For example, I can see below processes on my system:
  184 root         0 SW   [spi32766]
and our QSPI driver don't use IRQs.
 

> [4] Patch to implement SPI RT in device tree: http://www.spinics.net/lists/arm-kernel/msg348713.html
> 

-- 
regards,
-grygorii

Re: cyclictest versus custom SPI based system

[Julio Cruz Barroso]

Hi Griygirii,

Yes, I got the same results. 

Julio

On Jan 15, 2016, at 7:31 PM, Grygorii Strashko <grygorii.strashko@ti.com> wrote:

Hi Julio,
> On 01/14/2016 10:11 AM, Julio Cruz Barroso wrote:
> 
> I changed the policy:priority as you suggested and the system is stable now!! I will prepare
an application to measure the latency with some loads during long periods (but this is another thing).
> 
> For reference, in my case (iMX6), the priority adjustment was done at spi.c (master->rt). A patch
was suggested to implement this by device tree but other opinion said that this sound like a Linux
specific feature/implementation [4]. Anyways, this is another issue.

Just curios, is it possible for you to achieve the same results from User space using chrt/taskset utils?
(without Kernel modification).

For example, I can see below processes on my system:
 184 root         0 SW   [spi32766]
and our QSPI driver don't use IRQs.


> [4] Patch to implement SPI RT in device tree: http://www.spinics.net/lists/arm-kernel/msg348713.html

-- 
regards,
-grygorii