What is the correct IRQ number for EPIT in the Linux kernel?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

What is the correct IRQ number for EPIT in the Linux kernel?

Jump to solution
2,874 Views
kevinroussel
Contributor II

Hello,

I am still developing a Linux kernel module -- on a i.MX6UL-based embedded system -- to wake up my system from suspend mode after some delay, using the EPIT to raise an interrupt. (I already asked a question for this work here : Why does my i.MX6UL-based Linux system freezes when accessing IO memory?)

I am now trying to install an interrupt handler reacting to EPIT interrupts. Calling the request_irq kind of works... except I don't actually have the correct IRQ number!

The iMX6UL manual (chapter 3) indicates that the EPIT1 irq number is 88 (from which you visibly need to subtract 32).

However, it is not the IRQ number actually used by Linux!

When my module is loaded, the /proc/interrupts file shows:

      CPU0
 16: 873381      GPC  55 Level i.MX Timer Tick
 17:      0      GPC  20 Level snvs-secvio
 19:    867      GPC  33 Level 2010000.ecspi
 20:      0      GPC  34 Level 2014000.ecspi
 21:      0      GPC  39 Level 2018000.serial
 22:   8559      GPC  26 Level 2020000.serial
 23:      0      GPC  40 Level 2024000.serial
 24:      0      GPC  50 Level 2034000.asrc
 56:      0 gpio-mxc  23 Edge  Module d'essai EPIT i.MX6-UL
169:      0 gpio-mxc   0 Edge  gpiolib
201:      0      GPC   4 Level 20cc000.snvs:snvs-powerkey
204:      0      GPC  49 Level imx_thermal
213:    575      GPC   2 Level sdma
219:      0      GPC  43 Level 2184000.usb
220:   4151      GPC  42 Level 2184200.usb
221: 134575      GPC 118 Level 2188000.ethernet
222:      0      GPC 119 Level 2188000.ethernet
223:  16418      GPC  22 Level mmc0
224: 133310      GPC  23 Level mmc1
225:      0      GPC  38 Level 21a8000.i2c
227:      0      GPC  27 Level 21e8000.serial
228:      0      GPC  28 Level 21ec000.serial
229:      0      GPC  29 Level 21f0000.serial
230:      0      GPC  30 Level 21f4000.serial
231:      0      GPC  17 Level 21fc000.serial
232:     14      GPC 105 Level 2141000.jr0
233:      0      GPC 106 Level 2142000.jr1
234:      0      GPC  46 Level 2143000.jr2
IPI0:     0 CPU wakeup interrupts
IPI1:     0 Timer broadcast interrupts
IPI2:     0 Rescheduling interrupts
IPI3:     0 Function call interrupts
IPI4:     0 Single function call interrupts
IPI5:     0 CPU stop interrupts
IPI6:     0 IRQ work interrupts
IPI7:     0 completion interrupts
Err:      0

The IRQ number you give to the function request_irq corresponds to the first column of the /proc/interrupts file, while the IRQ numbers given by the reference manual corresponds to the fourth column!

I cannot find what IRQ number to use in order to actually install the interrupt handler for EPIT...

Does anybody know how to find the appropriate IRQ number?

Thanks in advance,

PS: my system runs Debian Linux 8 ("Jessie"), and thus the version 4.1.15 of the Linux kernel. The source for my module is attached.

Labels (2)
0 Kudos
1 Solution
2,585 Views
kevinroussel
Contributor II

Hello jimmy,

Unfortunately no, I have to use interruption number 56/88 of the GPC. The content of /proc/interrupts given in my question shows that the IRQ allocation process went completely wrong.

Actually, It looks like Linux on ARM only uses dynamically-assigned IRQ numbers.

I had to change my module into a full-fledged platform driver in order to have Linux correctly allocate a dynamic IRQ number for the interruption I had to handle. Here is the current, expected, and working result:

# cat /proc/interrupts
        CPU0
 16:  3702597  GPC        55  Level  i.MX Timer Tick
 17:        0  GPC        20  Level  snvs-secvio
 19:      123  GPC        33  Level  2010000.ecspi
 20:        0  GPC        34  Level  2014000.ecspi
 21:        0  GPC        39  Level  2018000.serial
 22:      946  GPC        26  Level  2020000.serial
 23:        0  GPC        40  Level  2024000.serial
 24:        0  GPC        50  Level  2034000.asrc
156:        0  gpio-mxc   21  Edge   Right
157:        0  gpio-mxc   22  Edge   Down
158:        0  gpio-mxc   23  Edge   Up
159:        0  gpio-mxc   24  Edge   Left
169:        0  gpio-mxc    0  Edge   gpiolib
201:        0  GPC         4  Level  20cc000.snvs:snvs-powerkey
204:        0  GPC        49  Level  imx_thermal
209:       19  GPC        56  Level  EPIT i.MX6UL platform driver (VENATHEC)
210:       19  GPC        57  Level  EPIT i.MX6UL platform driver (VENATHEC)
215:       80  GPC         2  Level  sdma
221:        0  GPC        43  Level  2184000.usb
222:    14464  GPC        42  Level  2184200.usb
223:   427647  GPC       118  Level  2188000.ethernet
224:        0  GPC       119  Level  2188000.ethernet
225:    77514  GPC        22  Level  mmc0
226:  1238480  GPC        23  Level  mmc1
227:        0  GPC        38  Level  21a8000.i2c
229:        0  GPC        27  Level  21e8000.serial
230:        0  GPC        28  Level  21ec000.serial
231:        0  GPC        29  Level  21f0000.serial
232:        0  GPC        30  Level  21f4000.serial
233:        0  GPC        17  Level  21fc000.serial
234:       15  GPC       105  Level  2141000.jr0
235:        0  GPC       106  Level  2142000.jr1
236:        0  GPC        46  Level  2143000.jr2
IPI0:       0  CPU wakeup interrupts
IPI1:       0  Timer broadcast interrupts
IPI2:       0  Rescheduling interrupts
IPI3:       0  Function call interrupts
IPI4:       0  Single function call interrupts
IPI5:       0  CPU stop interrupts
IPI6:       0  IRQ work interrupts
IPI7:       0  completion interrupts
Err:  0

The final answer to my question (for those who would need the answer in the future is) : you have to make a platform driver to handle correctly an IRQ within a Linux module, at least on embedded ARM platform.

View solution in original post

2 Replies
2,584 Views
jimmychan
NXP TechSupport
NXP TechSupport

looks like this is a gpio interrupt.

0 Kudos
2,586 Views
kevinroussel
Contributor II

Hello jimmy,

Unfortunately no, I have to use interruption number 56/88 of the GPC. The content of /proc/interrupts given in my question shows that the IRQ allocation process went completely wrong.

Actually, It looks like Linux on ARM only uses dynamically-assigned IRQ numbers.

I had to change my module into a full-fledged platform driver in order to have Linux correctly allocate a dynamic IRQ number for the interruption I had to handle. Here is the current, expected, and working result:

# cat /proc/interrupts
        CPU0
 16:  3702597  GPC        55  Level  i.MX Timer Tick
 17:        0  GPC        20  Level  snvs-secvio
 19:      123  GPC        33  Level  2010000.ecspi
 20:        0  GPC        34  Level  2014000.ecspi
 21:        0  GPC        39  Level  2018000.serial
 22:      946  GPC        26  Level  2020000.serial
 23:        0  GPC        40  Level  2024000.serial
 24:        0  GPC        50  Level  2034000.asrc
156:        0  gpio-mxc   21  Edge   Right
157:        0  gpio-mxc   22  Edge   Down
158:        0  gpio-mxc   23  Edge   Up
159:        0  gpio-mxc   24  Edge   Left
169:        0  gpio-mxc    0  Edge   gpiolib
201:        0  GPC         4  Level  20cc000.snvs:snvs-powerkey
204:        0  GPC        49  Level  imx_thermal
209:       19  GPC        56  Level  EPIT i.MX6UL platform driver (VENATHEC)
210:       19  GPC        57  Level  EPIT i.MX6UL platform driver (VENATHEC)
215:       80  GPC         2  Level  sdma
221:        0  GPC        43  Level  2184000.usb
222:    14464  GPC        42  Level  2184200.usb
223:   427647  GPC       118  Level  2188000.ethernet
224:        0  GPC       119  Level  2188000.ethernet
225:    77514  GPC        22  Level  mmc0
226:  1238480  GPC        23  Level  mmc1
227:        0  GPC        38  Level  21a8000.i2c
229:        0  GPC        27  Level  21e8000.serial
230:        0  GPC        28  Level  21ec000.serial
231:        0  GPC        29  Level  21f0000.serial
232:        0  GPC        30  Level  21f4000.serial
233:        0  GPC        17  Level  21fc000.serial
234:       15  GPC       105  Level  2141000.jr0
235:        0  GPC       106  Level  2142000.jr1
236:        0  GPC        46  Level  2143000.jr2
IPI0:       0  CPU wakeup interrupts
IPI1:       0  Timer broadcast interrupts
IPI2:       0  Rescheduling interrupts
IPI3:       0  Function call interrupts
IPI4:       0  Single function call interrupts
IPI5:       0  CPU stop interrupts
IPI6:       0  IRQ work interrupts
IPI7:       0  completion interrupts
Err:  0

The final answer to my question (for those who would need the answer in the future is) : you have to make a platform driver to handle correctly an IRQ within a Linux module, at least on embedded ARM platform.