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