• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 2681 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.

Beaglebone Black Interrupt Linux

Sean Moffatt
Intellectual 330 points

Hi,

I'm trying to test handling of interrupts on a Beaglebone Black board with TI's Linux SDK v.8 kernel v. and I have observed the following strange behaviour.

For example if I call request_irq for Interrupt 86 (ePWM0INT according to the AM335x Sitara Technical Reference Section 6.3) it will report an error that conflicts with the i2c which is interrupt 70 (I2C0INT).

Upon some further investigation I noticed that when I call request_irq, the irq line number I provide needs to be offset by 16.  Any calls with irq line numbers below 16 will fail.

For example the following is the output of /proc/interrupts/ before I load my module with a call to request_irq.

cat /proc/interrupts
           CPU0      
 28:       3793      INTC  12  edma
 30:         87      INTC  14  edma_error
 33:          0      INTC  17  47400000.dma-controller
 34:          0      INTC  18  musb-hdrc.0.auto
 35:          1      INTC  19  musb-hdrc.1.auto
 44:        366      INTC  28  mmc1
 52:          0      INTC  36  tilcdc
 53:          1      INTC  37  SGX ISR
 56:          0      INTC  40  4a100000.ethernet
 57:        338      INTC  41  4a100000.ethernet
 58:        147      INTC  42  4a100000.ethernet
 59:          0      INTC  43  4a100000.ethernet
 80:      11293      INTC  64  mmc0
 84:       6472      INTC  68  gp_timer
 86:       1631      INTC  70  44e0b000.i2c
 88:       1514      INTC  72  OMAP UART0
 91:          0      INTC  75  rtc0
 92:          0      INTC  76  rtc0
 93:          0      INTC  77  wkup_m3
 94:          1      INTC  78  wkup_m3_txev
125:         66      INTC 109  53100000.sham
127:          0      INTC 111  48310000.rng
150:          0  44e07000.gpio   6  mmc0
Err:          0

Then I load my module with request_irq for interrupt 102 and the output of /proc/interrupts reflects that I have a handler for interrupt 86.

cat /proc/interrupts
           CPU0      
 28:       3808      INTC  12  edma
 30:         87      INTC  14  edma_error
 33:          0      INTC  17  47400000.dma-controller
 34:          0      INTC  18  musb-hdrc.0.auto
 35:          1      INTC  19  musb-hdrc.1.auto
 44:        366      INTC  28  mmc1
 52:          0      INTC  36  tilcdc
 53:          1      INTC  37  SGX ISR
 56:          0      INTC  40  4a100000.ethernet
 57:        476      INTC  41  4a100000.ethernet
 58:        200      INTC  42  4a100000.ethernet
 59:          0      INTC  43  4a100000.ethernet
 80:      11368      INTC  64  mmc0
 84:       7769      INTC  68  gp_timer
 86:       1643      INTC  70  44e0b000.i2c
 88:       1514      INTC  72  OMAP UART0
 91:          0      INTC  75  rtc0
 92:          0      INTC  76  rtc0
 93:          0      INTC  77  wkup_m3
 94:          1      INTC  78  wkup_m3_txev
102:          0      INTC  86  test_module
125:         66      INTC 109  53100000.sham
127:          0      INTC 111  48310000.rng
150:          0  44e07000.gpio   6  mmc0
Err:          0


This behaviour also occurring on TI's Linux SDK v.7 with kernel v.3.12.10-ti2013.12.01 .

I'm wondering if someone could explain why the interrupt requested needs to be offset by 16?

Thanks,
Sean

  • 0
    TI__Guru**** 393215 points

    Hi Sean,

    I will forward this to the SW team.

  • 0
    Expert 1185 points

    Hi Sean,

    to answer your question, please refer to these concepts: interrupt controller, interrupt number and IRQ number.
    The first column in /proc/interrupts presents IRQ number, while the 3rd column is type of interrupt and interrupt number.
    The purpose of interrupt controller is to map IRQs to interrupt numbers.

    The first 16 IRQs are, probably, reserved for legacy devices, for ISA controllers.


    BR,
    Georgi

  • 0 in reply to Georgi Karpov
    Intellectual 330 points
    Georgi,

    That seems to be the issue. Parsing through dmesg I did see the following.

    [ 0.000000] NR_IRQS:16 nr_irqs:16 16
    [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts

    If I specify the interrupt number as 86 in my device tree, when I call platform_get_irq it provides the proper mapping.

    Thanks,
    Sean