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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
