GPIO IRQ Handler crashing kernel

[iMxGuy]

Hi,

I am having trouble trying to setup a GPIO input as an interrupt to a driver. When I ground the GPIO pin, the kernel is crashing. I have requested the irq I want to use and I do not get an error so I don't know why the kernel crashes. I am using BSP L2.6.35_10.12.01. Here is some snippets of my code.

if (mxt->irq) {
  /* Try to request IRQ with falling edge first. This is
  * not always supported. If it fails, try with any edge. */
  printk(KERN_WARNING "register irq handler: irq = %i, address = %p, flags = %i, name = %s\n",
  mxt->irq, mxt_irq_handler, IRQF_TRIGGER_FALLING, client->dev.driver->name);

  error = request_irq(mxt->irq, mxt_irq_handler, IRQF_TRIGGER_FALLING, "IRQ_ATMEL_TOUCH");

}

Here is the output from cat /proc/interrupts. IRQ 151 is the interrupt that I am using.

root@freescale ~$ cat /proc/interrupts
CPU0
6: 0 - pswitch
17: 261 - mxs-kbd
25: 70275 - mxs-kbd
38: 0 - fb_irq
39: 0 - mxs-pxp
41: 18295 - GPMI NFC BCH Interrupt
47: 159 - DebugUART
48: 3873 - i.MX/mxs Timer Tick
52: 0 - dcp
53: 6 - dcp
69: 44 - mxs-i2c
82: 13 - mxs-mmc dma
84: 0 - mxs-spi.0
88: 79539 - GPMI NFC DMA Interrupt
92: 0 - fsl ehci pre interrupt, ehci_hcd:usb2
93: 291 - fsl ehci pre interrupt, ehci_hcd:usb1
94: 0 - usb_wakeup
95: 0 - usb_wakeup
96: 12 - mxs-mmc error
98: 0 - mxs-spi.0
110: 66 - mxs-i2c
151: 0 - IRQ_ATMEL_TOUCH
FIQ: mxs-battery
Err: 0

I am not setting up a Resource for this GPIO pin. Is that possibly the problem. I could use some examples on how to configure the GPIO pins for interrupts and using them in a device driver.

[YS]

I should mention that the GPIO0 IRQ issue is already addressed by Freescale patch 588 (included in "Linux patches for i.MX28 SDK 2010.12"). Their implementation is slightly different from mine but essentially the same type of fix.

[lategoodbye]

Does the problem exists in current Mainline Kernel 3.10?

I just ask because the file to patch doesn't exist. I think it moved all to irqchip/irq-mxs.c.

[CraigMcQueen]

Actually it's in Freescale patch 581.

I came across this bug too, and appreciated your post--saved me a lot of debug time. Thanks very much for explaining the situation.

[YS]

I just encountered same issue and come across this article. It was very helpful to pull me out from wasting my time to investigate GPIO group0. Thank you.

I solved this issue by adding 2 lines in kernel interrupt dispatcher macro to check ISR bit 31 in HW_ICOLL_RAW3 to tell false interrupt from IRQ #127. The file is arch/arm/plat-mxs/include/mach/entry-macro.S.

    .macro    get_irqnr_and_base, irqnr, irqstat, base, tmp

    ldr \base, =g_icoll_base
    ldr \base, [\base]
    ldr \irqnr, [\base, #0x70]
    cmp \irqnr, #0x7F
    bne 2f
    ldr \tmp, [\base, #0xD0]
    tst \tmp, #0x80000000
    moveqs \irqnr, #0
2:
    .endm

I confirmed I could use GPIO IRQ0 on Linux with this modification.

[MarcosNodar]

hi,

it is possible to have GPIO interrupts from bank 0 but indeed it needs some modification in low level irq handling code.

As you describe, "interrupt pending" condition is interpreted from HW_ICOLL_STAT value, which causes the problem when this value is 127, ie. the same as the interrupt number for GPIO bank 0. The workaround is to read the "interrupt pending" condition from HW_ICOLL_DEBUG register instead, which has a read only bit "IRQ" that provides the state of the IRQ line to the CPU. So when you get an interrupt, and read 127 from HW_ICOLL_STAT, it is because you got an interrupt from GPIO bank 0 !

[iMxGuy]

SOLVED. According to Freescale tech, you cannot use the GPIO in the first bank as an interrupt source. I switched to a different GPIO in a different bank, and it worked. As of now there is no patch for the BSP to fix this.

"Root cause is that in order to get the best performance for interrupt processing, in the low level code, we will only check the HW_ICOLL_STAT register, but for BANK 0 IRQ_GPIO0=127, it is same as the default value of HW_ICOLL_STAT, so irq 127 will not be detected by Linux BSP. This leads to the system crash."