• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 1765 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM572x interrupts delayed several seconds

Christopher Peters
Genius 3370 points
Other Parts Discussed in Thread: AM5728, SYSCONFIG

AM5728, PDK 1.0.2, Compiler V8.1.0, BIOS 6.45.1.29, XDC 3.32.0.06

Using the AM5728 on a custom board.  A15 running Linux, DSP core running SYS/BIOS.  Talking to an FPGA via PCIe, which seems to be working.  The FPGA sends an interrupt to the DSP via GPIO8_20.  GPIO8_20 is configured as an input and Rising Edge Triggered interrupt.  I manually checked the config registers for GPIO8 (0x48053130 and on) and see what I am expecting, Rising Edge Detect, No debounce. 

I put the interrupt line on a scope and I can see it trigger immediately after I send my command to the FPGA, so I know the FPGA is sending the interrupt to the AM5728 GPIO8_20 pin immediately.  My code that uses the interrupt times out at 6 msec, but I have seen the interrupt come in at anywhere from 2 - 15 seconds.  Yes, seconds.  I measured this by setting a different GPIO when I get the interrupt and the delay is as stated above.  Using the debugger and setting a breakpoint on the interrupt handler also has the same delay, 2-15 seconds.  The earliest function I can break on is GPIO_v1_hwiFxn() and I see the same delay to that function. 

So, everything I have looked at tells me there is a big delay between the interrupt arriving at the GPIO pin and the DSP core seeing the interrupt.  Any ideas what could cause such a long delay?

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Genius 3370 points
    Thanks Biser. I have some additional information. I read the TRM some more and looked into the GPIO_SYSCONFIG register (among others). It was showing a value of 0x0000001d. I changed it to 0x00000008 and the interrupts are now very fast. I have not determined If it was the IDLEMODE change or AUTOIDLE change that made the difference. However, I don't yet know how this register gets setup or how I can change it to be what we want.
  • 0 in reply to Christopher Peters
    Genius 3370 points
    Hello again, I'd still like to get some guidance on this issue. I don't like manually writing registers in my code, seems like the TI driver would handle this.

    Recap:

    The system boots on Linux and then Linux boots the DSP which uses GPIO based interrupts. By default interrupts are delayed 2-15 seconds. Inspection of the GPIO_SYSCONFIG register showed a value of 0x0000001D. This told me that the GPIO was configured to AUTOIDLE = 1 and IDLEMODE = 3. I then manually set GPIO_SYSCONFIG to 0x00000008 which is IDLEMODE = 1 or No Idle and AUTOIDLE = 0 or clock is free-running. This fixed my problem and reduced interrupt latency to several hundred usecs.

    Since the reset value of GPIO_SYSCONFIG is 0, Linux must be writing this register before the DSP can and the DSP driver code does have high level functions to set this mode.
  • 0 in reply to Christopher Peters
    TI__Guru**** 161600 points
    Hi,

    I then manually set GPIO_SYSCONFIG to 0x00000008 which is IDLEMODE = 1 or No Idle and AUTOIDLE = 0 or clock is free-running. This fixed my problem and reduced interrupt latency to several hundred usecs.


    Can you try adding
    ti,gpio-always-on
    to the gpio dts node?

    This should also tell the driver to set the gpio to No Idle & clock should be always on.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 1290 points

    Hello,

    I'm working with Chris on this issue. I added the "ti,gpio-always-on;" property to the device tree for each of the banks of interest but we saw no modification to the GPIO configuration registers.

    I sort of expected this, as I searched the entire Linux source tree for references to the "ti,gpio-always-on" property and only saw references:

    • Within the Documentation folder
    • Within a collection of TI/OMAP device trees

    Was this property removed from the OMAP GPIO driver at some point?

    Thanks

  • 0 in reply to Gerard
    TI__Guru**** 161600 points
    Hi,

    Apologies for the delayed response.
    Was this property removed from the OMAP GPIO driver at some point?


    No, I am not aware of removing this functionality...

    Have you tried doing a __raw_write() to the GPIO_SYSCONFIG register? This could be done in the probe function after applying the dts settings.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 1290 points

    Yordan Kovachev said:

    Have you tried doing a __raw_write() to the GPIO_SYSCONFIG register? This could be done in the probe function after applying the dts settings. 

    No, I have no tried doing that but that's essentially what Chris mentioned he did above from within the DSP software. So, I'm sure it would also work if I manually do it from Linux.

    On the Linux side I would have expected the value of the "ti,gpio-always-on" property to be read by the OMAP GPIO driver, causing it to set the appropriate value in the GPIO_SYSCONFIG. Again, I see no references to the property actually being used within the Linux kernel shipped with Processor SDK 02.00.02.11 (Linux 4.1.18+TI)  and Processor SDK 03.01.00.06 (Linux 4.4.19+TI).

    I do see it in much older kernels - like 3.12.10+TI - within drivers/gpio/gpio-omap.c. What's the preferred way to formally request this be readded?

    Thanks