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

Jason Thorpe <[email protected]> Thu, 19 Apr 2018 08:15:48 -0700
Newsgroups gmane.os.netbsd.devel.embedded
Message-ID <[email protected]>

> On Apr 19, 2018, at 12:31 AM, Manuel Bouyer <[email protected]> =
wrote:
>=20
> 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.
>>=20
>> Anyone have any solid examples?
>>=20
>> 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.
>>=20
>> I found Manuel Bouyer?s chart plotter driver that uses this on =
Github, but it seems to have some FDT conditionals, as well?
>=20
> 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=E2=80=99t 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 =E2=80=A6 seems analogous to building e.g. a game controller =
where you have anywhere between 4-10 momentary switches in a single =
logical device.  I=E2=80=99m already using the raw GPIO directly (to =
talk to a bank of shift registers).

Here=E2=80=99s kind of what I=E2=80=99m thinking=E2=80=A6

Have gpiokbd attach to gpio.  It=E2=80=99s 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 =E2=80=9Cattach-keyboard=E2=80=9D =
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 =E2=80=9Cdetach-keyboard=E2=80=9D 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=E2=80=99s 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.

>=20
> --=20
> Manuel Bouyer <[email protected]>
>     NetBSD: 26 ans d'experience feront toujours la difference
> --

-- thorpej