• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 104 subscribers
  • Views 4889 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.

AM335x GPIO Interrupt priority in Linux

semiyd
Expert 1600 points
Other Parts Discussed in Thread: AM3354

Hi

   I'm using AM3354 on linux 3.2.0.

  Right now i'm using gpio1_17 and gpio1_18 as an interrupt source.

  but i found that the response time between the real hardware interruption and the interrupt handler i registered with kernel is entered...is really long.

  normally it's at least 1ms.Sometimes it's 20ms.

  this gets me into a big trouble...

  How to change the interrupt of gpio1_17 and gpio1_18 to a much higher priority in linux for am3354?

thanks guys!

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the software team to comment.
  • 0
    TI__Guru**** 161600 points
    Hi,

    Have a look at Section 6.1.1.2.2 Priority Masking & Section 6.1.1.3 Priority Sorting in AM335x TRM. You need to set the priority of the corresponding interrupt in INTC_ILRm register.

    You should add the appropriate configurations either in gpio-omap.c, when preparing gpio interrups or in the INTC driver irq-omap-intc.c.

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

    Hi Yordan

        thanks a lot for the details!

        I checked the TRM and found that in 6.3 ARM Cortex-A8 Interrupts

       there are 2 different interruption source for GPIO1

    98 GPIOINT1A GPIO 1 POINTRPEND1
    99 GPIOINT1B GPIO 1 POINTRPEND2

       Because i was using gpio1_17 and gpio1_18 

       I suppose it should be INTC_ILR99 or INTC_ILR98. Right?

       Although i have no idea which one exactly it should be .INTC_ILR99 or INTC_ILR98.

      Another question is about the value of the priority.Is it more prioritized if the value is smaller? Or bigger?

    thanks again

    semiyd

  • 0 in reply to semiyd
    TI__Guru**** 161600 points

    Hi,

    semiyd said:

       I suppose it should be INTC_ILR99 or INTC_ILR98. Right?

    Yes those are the two registers. 

    semiyd said:

       Although i have no idea which one exactly it should be .INTC_ILR99 or INTC_ILR98.

    Have a look at Section 25.3.3.2 Synchronous Path: Interrupt Request Generation, Figure 25-3. Interrupt Request Generation, this would depend which interrupt line of the GPIO controller is enabled (depending on the settings of Interrupt Enable Register 1 or 2). 

    semiyd said:
    Another question is about the value of the priority.Is it more prioritized if the value is smaller? Or bigger?

     

    Lower value means higher priority. 

    Best Regards, 
    Yordan

  • 0 in reply to Yordan Kovachev
    Expert 1600 points

    thanks a lot Yordan!

  • 0 in reply to semiyd
    Prodigy 90 points
    Hello Yordan,

    I would like to inquire as to how set the interrupt priority levels within later versions of Linux as well. Can the device tree be used to set hardware interrupt priority levels in later kernel releases ? I realize that hardware interrupt priority levels can't be set within a say a driver's ISR, but is there a way to let the NVIC know which peripherals have certain priorities?

    Thanks,

    Ben
  • 0 in reply to Thomas Smith48
    TI__Guru**** 161600 points
    Hi Ben,

    Sorry for the delayed response.

    Can the device tree be used to set hardware interrupt priority levels in later kernel releases ?

    No, you cannot use the device tree for such purpose.

    In general linux kernel is not very flexible, regarding IRQ priority setting. Depending on the IRQ controller, you could (as I said earlier) program its registers to assign a irq priority to a certain line.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Mastermind 30276 points
    In addition to h/w priorities, this could also be a Linux thread scheduling priority issue. Since this is non-RT Linux, a 20ms delay is understandable. You could look at using Nice and thread priorities to try to improve this. However, non-RT Linux will never be able to gaurantee a certain scheduling delay.

    Also, as I'm sure you know, the 3.2 kernel is pretty old and we have SDKs available with up to a 4.4 kernel, as well as RT options.