• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 3402 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/AM5728: GPIO interrupt latency on IPU

Lo2
Expert 1935 points
Part Number: AM5728
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello,

I'm have the same issue as described a year ago in this thread:

https://e2e.ti.com/support/arm/sitara_arm/f/791/t/573071

I'm using GPIO8 (bit 20) to trigger the ISR in the IPU.

By default GPIO8 is routed to the A15 running Linux, I've disabled it in the device tree by setting the status of the entire gpio8 node to disabled:

&gpio8 {
    status = "disabled";
};

This deletes the IRQ from the IRQ_CROSSBAR map for the A15.

GPIO8 has two IRQs: 116 and 348. None of them is routed to the A15, IRQ1 (116) is routed to the IPU1 and triggers there a Hwi ISR.

The ISR on the IPU should then do four transfers on I2C bus 3 (also disabled in the DT, so the A15 does not see it).

The interrupt latency of the GPIO8 ISR on the IPU is around 500uS to 700uS which is way to long. Enabling IRQ1 and IRQ2 of the GPIO8 as described as workaround in the e2e thread linked above does solve the latency issue but causes the I2C transfers to be very slow: after (almost!) each transfer there's an additional delay. Some transfers are still fast back to back. I've got one on the scope screen shot below. Most of them are slow. A mix of slow/fast also happens.

My workaround for now is: enable IRQ1 and IRQ2 of GPIO8 and write my own I2C transfer routines in C using polling instead of interrupts.

- Why do I have the enable IRQ1 and IRQ2 for GPIO8 to get a low latency response? Is this a wrong config or a silicon bug?

- Why does the (pdk-) I2C transfer take such a long time?

I measured the I2C transfers:

Channel 1: trigger on GPIO8_20

Channel 2+3: I2C bus 3

Channel 4: GPIO4_4 to measure the time of a single i2c transfer

SLOW:

FAST:

The IPU1 and DSP1 both run sysbios, the DSP1, IPU1 and the A15 communicate over IPC.

IPU2 and DSP2 are not used.

Best regards,

Lo

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru* 95265 points
    Hi,

    I wonder if you can disable the Linux on A15, just ran the GPIO interrupt RTOS example on IPU core and only enable IRQ1, to see if you find slowness in ISR? Then, enable both IRQ1 and IRQ2, any change in ISR latency? This is to rule out if Linux issue or not?

    Regards, Eric
  • 0 in reply to lding
    Intellectual 310 points

    Hello.

    I can provide some screenshots taken by an oscilloscope during a standalone execution running on IPU under TI RTOS using TI's pdk driver (no bare-metal version):

    this is an overview during 8 pulses of GPIO8.20 (in yellow) and the following are more detailed pictures:

    As you can see I2C transactions are completed before the next rising edge of GPIO8.20 and everything is running in the contest of an high priority task pending on an event posted by the callback of GPIO isr.

    I have other traces showing mainly the latency of I2C activity compared to GPIO interrupt that I can summarize in the following way:

    1) Bare-metal I2C driver + ISR  (it means a call of a subset of I2C transactions in ISR): latency ~ 3us

    2) Bare-metal I2C driver + SWI : latency ~ 9us

    3) TI's multi-thread safe I2C driver + high priority task (handler task) : latency ~ 14 us

    In any case, under TI RTOS without Linux+IPC, I never saw problems reported by Lo2.

    Best Regards,

    Scianni Vincenzo 

  • 0 in reply to Vincenzo Scianni54
    TI__Guru 50170 points
    Hi, Vincenzo,

    When the interrupt slowness happens, what applications are running on Linux? and what was running across IPC? what cores are involved in IPC communication? and which Processor SDK release are you using?

    Rex
  • 0 in reply to Rex Chang
    Expert 1935 points

    Hello Rex,

    We're running SDK 04.01.00.06 (ti-processor-sdk-linux-am57xx-evm-04.01.00.06).

    There are some basic MessageQ messages being sent via IPC:

    We have IPC setup between DSP (1 core) <-> Linux (2x A15) and IPU (1x dual-M4) and Linux (2x A15). IPU2 and DSP2 are not used.

    The IPC between DSP and Linux is not very active: there is only an idle loop on the DSP that sends a alive message once a second. For the rest of the time the DSP sleeps.

    The IPU1 sends some status messages via IPC, but not much.

    On the Linux host there is not much active besides our application, the CPU load is <5%. It starts the external sensor (which generates the interrupts on GPIO8 for the IPU).

    There is no other application active (no matrix launcher, no webserver,...)

    Best regards,

    Lo2

  • 0 in reply to Lo2
    Expert 1935 points
    Any update on this?
  • 0 in reply to Lo2
    TI__Guru* 95265 points

    We have a similar issue on https://e2e.ti.com/support/embedded/linux/f/354/p/582007/2197295 Not sure if you can try to put IPU on deepsleep if this helps?

    Regards, Eric

  • 0 in reply to lding
    Expert 1935 points

    Hi Eric,

    the application runs some code continuously and has a high priority thread to handle actions triggered by the interrupt. Putting the IPU in deep sleep is not really useful for this setup.
    I can image that there is less jitter if the IPU wakes up from deep sleep (as it's always the same flow) compared to a running IPU (where the scheduler might need to suspend a running task).
    The jitter is not a problem for this use case but the total latency is. (sum of worst case jitter and worst case latency)

    In the original post we have a latency of 500-700uS, we 'fixed' it by routing an unused irq to the ipu. For our use case it is now fast enough and the jitter is within a reasonable boundary (as far as I can tell right now).

    The 500-700uS latency cause is not understood, is it due to a missing clock config? a hardware issue of the crossbar?


    Best regards,
    Lo2

  • 0 in reply to Lo2
    TI__Guru 50170 points
    There was a similar issue in one of the old posts, e2e.ti.com/.../561674. the issue seems to be that both ARM and DSP were serving the same interrupt. The GPIO8 is disabled by setting the status to disabled in your case. I checked the gpio kernel code, driver doesn't check status through of_device_is_available(). So, the GPIO8 isn't disabled. Could you try commenting out the gpio8 node in dts file?
  • 0 in reply to Rex Chang
    TI__Guru 50170 points
    Hi, Lo2,

    Not sure if you have tried to disable the GPIO as mentioned in previous post, and if it helps.
    If that resolved the issue, please click "Resolved". If you have other issue, please submit a new one.

    Rex
  • 0 in reply to Rex Chang
    Expert 1935 points

    Hi Rex,

    The gpio8 is disabled in the devicetree (the whole bank). Linux does not use any of the gpio8 signals, they are used by the IPU only. Both gpio8 interrupts are routed to the IPU, not the A15.

    We don't miss interrupts but have a very high latency for the gpio interrupt on the IPU.

    As workaround we configure the IRQ crossbar to assign both interrupt of gpio8 to the IPU. The latency is much better, but there still is much jitter.

    Best regards,

    Lo

  • 0 in reply to Lo2
    TI__Guru 50170 points
    Lo,

    Thanks for the info. I'll close the thread.

    Rex