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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Apr 19, 2018 at 08:15:48AM -0700, Jason Thorpe wrote:
> 
> 
> > 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.

The DTB is here to describe the hardware; with hardware such as RPIs
we indeed change the hardware when connecting something to the GPIOs or
i2c/spi busses. Both sides needs to cooperate and the device tree is there
to make the link between the different elements.

Extending and rebuilding a fdt is easy in our tree.

> It also seems kind of silly to have a separate driver instance for each button ?

True; but it doens't have to be this way. For LEDs there is a single
driver instance AFAIK.

> 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.


I'm not sure you can do something general enough this way. For example
you may need to configure pullup/pulldown state of the GPIO, and some
controllers may allow different pull levels. The FDT can address this,
with MD-specific nodes under a MI node. For example look at allwinner,*
properties in our fdt trees.

BTW I just noticed we have fdt gpiokeys driver, which looks like what you
want.

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