GPIO in the kernel: an introduction [LWN.net]

GPIO in the kernel: an introduction

Posted Oct 3, 2016 19:12 UTC (Mon) by annonch (guest, #111527)
Parent article: GPIO in the kernel: an introduction

Is it possible to register an interrupt to both falling edge and rising edge and then distinguish which case it is inside the interrupt handler?

When I try to register two interrupts I get an error resource is busy, I think because it is the same irq_number (-16)

When I try to register the interrupts with the IRQF_SHARED | IRQF_TRIGGER_RISING flags I get Invalid argument (-22)

So I create a interrupt with flags IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING but when the interrupt is called, I want to distinguish the two conditions separately.

It is an arm device with kernel 4.4.21

Any advice? :)

to post comments

GPIO in the kernel: an introduction

Posted Oct 3, 2016 19:27 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (10 responses)

> Is it possible to register an interrupt to both falling edge and rising edge and then distinguish which case it is inside the interrupt handler?

Generally speaking, no. I'm not familiar with your specific platform, but typically one configures the interrupt controller to look for either a rising edge or a falling edge (or low/high level) for each input and it generates a single interrupt when that event occurs. As a result, there is no way to statically configure it to watch for both rising and falling edges.

You could try dynamically reconfiguring the interrupt—set it as falling-edge in the rising-edge handler, and vice-versa—but performance would probably become an issue and you might miss some events depending on how long the handler is delayed. A better option, if you control the wiring and have a spare interrupt-capable GPIO, would be to route the same signal to two separate pins and set up a handler for each pin, one rising-edge and one falling-edge.

GPIO in the kernel: an introduction

Posted Oct 3, 2016 22:58 UTC (Mon) by annonch (guest, #111527) [Link]

Wow thank you for the suggestion, it seems to work perfectly! I have configured an additional pin fed with the same signal and I think this method will work well for my project. :)

GPIO in the kernel: an introduction

Posted Dec 13, 2016 14:20 UTC (Tue) by bla (guest, #112986) [Link] (8 responses)

Anything speaking against using gpio_get_value in the isr to discern between rising and falling?

GPIO in the kernel: an introduction

Posted Dec 13, 2016 14:56 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (7 responses)

> Anything speaking against using gpio_get_value in the isr to discern between rising and falling?

The ISR will only run on the rising edge _or_ the falling edge, not both, so gpio_get_value will generally return a known result: either high for a rising-edge-triggered interrupt, or low for falling-edge.

GPIO in the kernel: an introduction

Posted Dec 13, 2016 16:46 UTC (Tue) by bla (guest, #112986) [Link] (6 responses)

Why wouldn't IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING with request_irq work?

GPIO in the kernel: an introduction

Posted Dec 13, 2016 18:28 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (5 responses)

> Why wouldn't IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING with request_irq work?

Things may be different on ARM or x86, but in my work on embedded PowerPC targets I have yet to see an interrupt controller than can be configured to trigger on both rising and falling edges for the same signal. Typically there are four possible trigger modes, of which only one can be active at a time: rising edge, falling edge, high level, or low level.

GPIO in the kernel: an introduction

Posted Dec 13, 2016 19:11 UTC (Tue) by bla (guest, #112986) [Link]

Ah, probably a gpio-controller/IRQ line limitation. I'll check if it works on a Raspberry (should, as Wiring has a BOTH option).

GPIO in the kernel: an introduction

Posted Dec 15, 2016 11:07 UTC (Thu) by bla (guest, #112986) [Link] (3 responses)

Ok, you c a n set a combined interrupt mask and query the pin state in the ISR on an RPi, but gpio_get_value seems to have latency, which makes this approach pretty much useless in conjunction with switch bounce and the ISR time constraints.
For implementing long button presses, detecting the first flank and reading the level with a thread after some delay seems to be the better approach, it also doesn't require a state change to trigger the long press signal.

GPIO in the kernel: an introduction

Posted Dec 15, 2016 20:05 UTC (Thu) by BlueLightning (subscriber, #38978) [Link] (2 responses)

Surely the answer to switch bounce is to do the debouncing in hardware?

GPIO in the kernel: an introduction

Posted Dec 15, 2016 20:32 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

But hardware debounce would require adding extra $0.02 worth of components and growing your board size by 2 square millimeters.

Why spent that money on every unit when it can be done once, "for free" in software?

GPIO in the kernel: an introduction

Posted Dec 17, 2016 6:44 UTC (Sat) by flussence (guest, #85566) [Link]

Fun trivia: this is exactly what the NES Classic does. In their GPL code dump there's a kernel driver for the controller - it has the same wire protocol the Wiimote uses (internally!), but leaves the kernel to deal with all that hardware-related insanity and more.