AM3358: change UART interrupt priority

Hi Shine,

Linux by design doesn't guaranty latency, I don't think increasing interrupt priority, if possible (I didn't look into it), would solve the issue.

Has the customer tried RT Linux instead?

Shine said:

The serial port is attached to the external serial chip by way of GPMC; the interrupt of uart is triggered by the GPIO_0_26, this IO level changes, they send data to the uart FIFO or read data from the uart FIFO;

I am not sure I understand the design. Could you please explain it? Maybe a diagram would help me to understand it?

Hello Bin

please see the diagram above, our IRDA uart chip communicates with AM3354 via GPMC interface, and if IRDA UART chip receives data from stm32 or data sends to stm32 completed will use GPIO_0_26 trigger a interrupt to the AM3354.

as we know, if use 8250 UART interrupt to send data, it will splite data to several small packets with 64 bytes, and if the 8250 UART interrupt can be processed on time, the time delay between each small packet will be small.  but we found some times the latence is too big! this make us drope in big trouble!

currenttly, the interrupt priority of GPIO_0_26 is too low, the GPIO_0_26 interrupt couldn't be processed on time! please see below

if we can raise the interrupt priority of GPIO_O_26, it's possible to help us fix the issue. no matter we use RT-linux or not, raise the priority is necessary to us!

as we know, am3354 can change the interrupt priority by  MPU_INTC.INTC_ILRm register, i try to add below code in the irq-omap-intc.c file

    intc_context.ilr[96] = 1<<2;
    intc_context.ilr[97] = 1<<2;

	for (i = 0; i < omap_nr_irqs; i++)
		intc_writel(INTC_ILR0 + 0x4 * i,
				intc_context.ilr[i]);

after we doing this, the kernel couldn't boot up, if you can tell us how to increase the GPIO_0_26 priority in the kernel 5.10 i will be appreciate it. thanks!

Hi Sean,

In most cases, the latency comes from kernel scheduling to handle the isr, not the interrupt priority in the interrupt controller.

Hello Bin

so, do you have suggestion on how to optmize the UART latency?

when we use kernel2.6, the UART latency is suit for our communication, if we update to kernel 5.10, the latency is our big trouble! we check the interrup source in the kernel 5.10, we found above the UART interrupt, there is more interrupts in kernel 5.10 than in kernel 2.6. so, it's worth to try to raise the priority.

Hi Sean,

kernel 2.6 is a decade old, as kernel version advances, its architecture also changes. Given its non-RT nature, I am not sure it is easy to control the latency in kernel.

Have you tested with RT kernel to see if the latency improves?

hello Bin

I had installed RT-linux patch,  but the interrutp latency still exist, as i know, RT-linux provide preempt mechnism, high priority can preempt low priority, currenttly, our UART interrupt is the lowest prioirty, so up the UART piority is still the best way for us.

Hi Sean,

This is not about UART interrupt, but the GPIO interrupt priority, right?

I will check if it is possible to change its priority.

Hi Bin

yes, it's GPIO_0_26 interrupt priority.

if you can provide details operation steps in kernel5.10, it will be more helpful to me, thank you very much!

Thanks. I will look into next week.

thanks for your support！looking forward your operation guidance.

Hi Bin

Have any update on this topic? thanks!

Hi Sean,

I didn't find a clear way to change the interrupt priority. But I don't think the issue is about the hw interrupt priority, rather how soon the kernel to schedule the irq handler to write data to TX FIFO, for which I didn't think of a solution either.

I guess your current IDRA UART chip driver transmits up to 64 bytes per GPIO interrupt? Does your IDRA UART chip provide information of available TX FIFO depth? If so, you might want to change the driver GPIO interrupt handler as below to transmit more bytes per GPIO interrupt?

irq_handler()
{
        u8 *txp = <tx buffer address>;
        int *data_len = <data length to be transmitted in tx buffer>;
        int tx_fifo_len;

        while (data_len > 0) {
                tx_fifo_len = <get IDRA UART available FIFO depth>;
                if (!tx_fifo_len)
                        /* tx fifo is full */
                        break;
                tx_fifo_len = (tx_fifo_len < data_len) ? tx_fifo_len : data_len;
                <write "tx_fifo_len" bytes from *txp to TX FIFO>;
                txp += tx_fifo_len;
                data_len -= tx_fifo_len;
        }
        return IRQ_HANDLED;
}

Hi Bin

thanks for your reply！

The irq_handler you provide seems similar with mine, in my project, when the tx FIFO available depth avbove 8 (or 16 or 32) it will trigger a interrupt to the am33xx MCU via GPIO. 

we have several channels of IRDA UART, each of them use different GPIO to trigger interrupt, currently, we optimize the kernel, such as raise HW interrupt priority, enable preempt configuration and other reference configurations, it seems works, but we need to close others channel  when one of them is sending the big packet,  all chennels can't work simultaneously, so it still looks like the linux kernel ack the GPIO interrupt too slow, it makes big latency!

Hi Sean,

Sean Wei said:

I had installed RT-linux patch,  but the interrutp latency still exist,

I am not sure what the RT linux patch is, but the Processor SDK Linux provides a RT Linux package. Please try to use it if possible.

After talked to our sw dev team, it should be possible to increase the priority of the GPIO irq handler in RT kernel. The developer will look into it and I will let you know once I have the update.

Hi Bin

thanks!

my RT patch is "patch-5.10.180-rt89-rc1.patch", it's not from TI SDK.

where can i get the RT linux package from Ti? can you please provide the URL? my kernel is version 5.10.166.

Hi Sean,

You can download Processor SDK v9.1 RT Linux package:
https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-9sG0TixXvC/09.01.00.001/ti-processor-sdk-linux-rt-am335x-evm-09.01.00.001-Linux-x86-Install.bin

It is listed in the page below.

https://www.ti.com/tool/PROCESSOR-SDK-AM335X (then select "PROCESSOR-SDK-LINUX-RT-AM335X").