Hello,
I found that latency of GPIO interrupt handlers is big and unstable.
On other ARM Cortex-A7 systems, for example i.MX6ULL, I used CONFIG_PREEMPT_RT enabled in kernel configuration to get interrupt latency stable in range 5-10 us.
Is it possible to use this option with Legato and WP76/77 modems? Any experience? Or other way to struggle with latency should be used?
With best regards, Sergey.
are you using the GPIO legato API in legato application?
How about using the GPIO interrupt in kernel driver layer and see if there is improvement?
You can also see if this helps to change the priority of irq:
I’m using GPIO interrupt in my linux kernel module.
I tested top half interrupt handler latencies, and it’s big, up to milliseconds latency. Test is made by switching logic level of other GPIO to see delay between interrupt signal rising edge, and second GPIO signal edge.
Average latency for GPIO interrupt for default kernel configuration is 600-700 microseconds. It corresponds to non-RT kernel configuration. That’s why I asked about PREEMPT_RT option and Legato.
how about increasing task priority?
How about changing IRQ priority ?
It’s only kernel module, no any application tasks. The module initializes two GPIOs, and contains only simple top half interrupt handler.
increasing task priority and changing IRQ priority are on kernel level
If you want to test CONFIG_PREEMPT_RT, you can try to add this in yocto source “./kernel/arch/arm/configs/mdm9607_defconfig” and recompile yocto image to see if there is any improvement
Kernel thread is used for bottom half handler, isn’t? I’m about latency of the top half handler.
In my case irq_desc.thread is NULL.
does irq priority belong to top half handler?
did you try to add CONFIG_PREEMPT_RT in yocto source?
During kernel build, some script removing CONFIG_PREEMPT_RT=y. I see it in defconfig, but not in .config in build tree.
so you confirm adding the flag in defconfig not work by downloading the yocto image to module, right?
does irq priority belong to top half handler?
Looks like linux 4.14.253 supplied with Legato 21.05 has no PREEMPT_RT patches included.
Because of this, interrupt priorities are also selected by the code in manage.c, and it’s impossible to change them from the kernel module. Or I’m wrong?
how about previous release with linux 3.18?
Do you confirm adding the flag in defconfig not work by downloading the yocto image to module?
Then have you changed it in manage.c to see if there is improvement?
The same, previous release also has no PREEMPT_RT patch.
Of course, I downloaded compiled image, but no any change in latency.
Without of RT-patch Linux have no possibility to fine-tune priorities in the APIC. The code in manage.c is related to bottom half (or threaded IRQ context):
static int
setup_irq_thread(struct irqaction *new, unsigned int irq, bool secondary)
{
struct task_struct *t;
struct sched_param param = {
.sched_priority = MAX_USER_RT_PRIO/2,
};
if (!secondary) {
t = kthread_create(irq_thread, new, "irq/%d-%s", irq,
new->name);
I’m requesting interrupt with IRQF_NO_THREAD flag and by request_irq() routine. It means that interrupt handler should be called in HARDIRQ context, not in kernel thread context.
The request_threaded_irq() call has two handler pointers: first will be called in HARDIRQ context “top half”, and second is “bottom half” will be called in kernel thread context.
The problem is in that HARDIRQ context has too much latency…
I have no idea then, you might need to contact distributor to get more support on this.
BTW, what is the problem right now on your side?
Is it affecting the bit-banging?
I’m exploring I/O capabilities of WP76/77 modems to decide about of architecture of my future device.
For low speed SPI I found spi-gpio already included in the kernel, and it works fine, so, I don’t need to invent my own bicycle.
I also have other peripherals normally with separate Cortex-M MCU with FreeRTOS and my software.
On GPIO interrupt I need to check state of 4 other GPIO lines in 0.5 milliseconds. Because I normally use PREEMPT_RT, I saw no problem here. Using Linux 5.6 and i.MX6ULL, for example, I got interrupt latency around 10 microseconds for “top half”. However, with WP77 I got 600 microseconds latency in average today.
i saw some internal discussion on this topic saying Linux is not a good environment for servicing time-critical interrupts.
If the user is looking for guaranteed interrupt latencies, it might not be able to provide that.
But as best-effort measurements the user could write their application code and use Linux FTRACE capability to estimate probabilities of interrupts being serviced within a time limit.
Yes, right. Mainline Linux Kernel is not very suitable for hard-RT tasks.
Of course, I can try to integrate PREEMPT_RT patches to the kernel. However, I have no detail information about how tightly the modem part is integrated with application part. If Linux and Legato running on pure dedicated CPU kernel, then things should be much easier, because its role limited to download BLOBs to the modem and initialize IPC channels to communicate with the modem. Otherwise, changes in kernel may cause issues with LTE communication.
By the way, should I use external hardware watchdog or it already implemented inside WP76/77 module?
You can see here