Re: Interrupts on GPIO (on RPI, specifically, but also in general)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Apr 19, 2018, at 12:31 AM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> 
> On Wed, Apr 18, 2018 at 10:28:34PM -0700, Jason Thorpe wrote:
>> There seems to be support for interrupts on GPIO, but no in-tree examples of how it?s used, programming patterns, etc.
>> 
>> Anyone have any solid examples?
>> 
>> Context: I have a device I?m building that is going to have some buttons, a switch or two, and a rotary encoder for input.  Path of least resistance is to use an AVR and an existing software library for said AVR to emulate a USB keyboard (the ?throw more hardware at the problem? approach).  But I have enough GPIO pins on the Raspberry Pi for the task and I loathe to make the PCB more complicated than it has to be, so I?m considering writing an interrupt-driven ?gpiokbd? driver that would allow me to map GPIO input pin interrupts to a configurable set of ?wskbd? input events.  I could poll, but I *really* don?t want too, and if I?m forced down that path, then I?d almost rather use the AVR solution.
>> 
>> I found Manuel Bouyer?s chart plotter driver that uses this on Github, but it seems to have some FDT conditionals, as well?
> 
> Yes. I don't know specifiacally for RPis (I don't use them), but for
> sunxi the GPIO driver is declared as an interrupt controller too.
> With a reference to a GPIO in the device tree a driver can
> use fdtbus_intr_str()/fdtbus_intr_establish(). This interface is MI.
> I think this is the way to go for your driver (and writing a
> FDT-based driver isn't hard :)

It just doesn’t seem right to make a new DTB for this purpose.  It also seems kind of silly to have a separate driver instance for each button … seems analogous to building e.g. a game controller where you have anywhere between 4-10 momentary switches in a single logical device.  I’m already using the raw GPIO directly (to talk to a bank of shift registers).

Here’s kind of what I’m thinking…

Have gpiokbd attach to gpio.  It’s dormant until configured.  The configuration of the pins (active hi/low, interrupt on rising/falling/both edges, and which keysym a pin maps to) would be specified in a property list.  An “attach-keyboard” ioctl would push the property list into the gpiokbd driver which would do all of the necessary setup and then attach the wskbd instance.  A separate “detach-keyboard” ioctl would detach the wskbd instance and disable any previously registered interrupt handlers.  The disposition of the GPIO pins themselves would be done in the usual way.

> BTW we have a gpiobutton driver, but AFAIK it uses polling.

Yes and it’s also very much oriented to single-button-with-system-control-function.  I may prototype the gpiokbd approach with polling first, and then add the interrupt capability later.

> 
> -- 
> Manuel Bouyer <bouyer%antioche.eu.org@localhost>
>     NetBSD: 26 ans d'experience feront toujours la difference
> --

-- thorpej