# GPIO Interrupts handling (ARM)



## aragats (Feb 25, 2016)

How to handle GPIO interrupts on BeagleBoard, Raspberry Pi etc. from the user space?
That's under TODO at:
https://wiki.freebsd.org/FreeBSD/GPIO
although the page was edited 1.5 years ago.


----------



## Juha Nurmela (Feb 26, 2016)

Do you know this https://svnweb.freebsd.org/base/head/sys/dev/gpio/ peephole ?

My wish is kqueue(2) support in GPIO.

Juha


----------



## aragats (Feb 26, 2016)

Yes, the wiki page I mentioned is referring namely to that. But there is nothing related to interrupts. Just checked gpioctl(8) from FreeBSD 11-CURRENT - it's not mentioning any interrupt configuration either.
In other discussions people advise to poll GPIOs instead, but that makes no sense in an embedded system.


----------



## Juha Nurmela (Feb 26, 2016)

I would say 700MHz makes no sense in an embedded system, but who am I to say anything 

Juha


----------



## aragats (Feb 26, 2016)

Exactly! I'd like to operate a Beagleboard at 50MHz, but you can't go below 300Mhz...


----------



## Phishfry (May 11, 2016)

I see this was recently added:
https://svnweb.freebsd.org/base?view=revision&revision=298738


----------



## aragats (May 11, 2016)

Sounds good, will take a look, thanks, Phishfry .


----------



## Daniel McRobb (Aug 13, 2016)

I'm wondering who's working on an overarching framework for GPIO and their corresponding interrupts.  I've written a few device drivers for the Raspberry Pi recently that interface to hardware via GPIO pins, and I'm using interrupts (and kqueue to communicate to user space).  For my needs, writing a specific device driver is perfectly reasonable since my hardware configurations are fixed (HATs I designed, complete hardware setup is dedicated to a particular set of tasks).  But I completely understand the desire to have GPIO interrupt facilities without having to write a device driver.

There are some quirks remaining with GPIO interrupts within the kernel that I haven't dug into yet.  There are cases where it's desirable to have separate handlers for rising and falling edge interrupts, but the 11.0-CURRENT I have right now doesn't allow it.  On my first pass at my rotary encoder driver, I found that gpio_alloc_intr_resource() failed for the second edge interrupt (order of rising or falling edge didn't matter).  I wound up working around it and moving on, but I am hoping to make time to look at it again.  Might already be fixed, I haven't had a chance to update in many weeks (or even open a bug report).  And of course it's entirely possible that I did something wrong, but from memory I reviewed my code thoroughly before deciding on a workaround.

I have a wish list in my head for GPIO functionality, but haven't written it down.  I do know I don't want to see the warts in Raspbian's solution to trickle into FreeBSD.  But I'd like to have per-pin permissions per ioctl (i.e. better access control granularity), be able to do more without changing the FDT, etc.  And of course efficient interrupts -> userspace.

If someone here know anyone who is working on such things, I'd be willing to help where I can.  Even if it's just helping flesh out what would be 'nice to have'.  I admit to not having a ton of time to contribute code outside of my immediate needs, but that's true of many of us who target FreeBSD in our spare time.  There's been quite a bit of change in the trunk since 10.x with respect to this stuff, but unfortunately I don't seem to be clued in to the set of design goals and I don't have enough different SBCs to understand what will work in the general case versus what only works on the Pis and BeagleBones.


----------



## Daniel McRobb (Aug 17, 2016)

I think a WG is a fine idea.  I'm sure that many of us have the same desires, as well as the same ideas.  Just coalescing them into something high level but cogent would be a good start and something I haven't yet seen for GPIO.

For some background... my bread and butter today is embedded development in the automotive industry.  But I spent 15 years of my career writing software for UNIX and I haven't stopped.  I've been running FreeBSD for various things professionally and at home for as long as I can remember (since the a.out and pre-SMP days).  My primary language for FreeBSD and UNIX work has been C++ for a long time (coming up on 20 years), but my day job is nearly all C.

Hardware-wise, today's off-the-shelf SBCs are very capable devices at low cost.  But there are those of us who'd like to bring the real differentiator of these platforms to bear (versus say a nanoITX x86 or amd64 platform) in our problem domains, on top of a freenix.  I want a  rock solid TCP/IP stack, filesystem, full POSIX APIs, real security facilities, etc.  But I also want at least the minimal set of embedded functionality too: a complete GPIO API, SPI, I2C, CAN.  Some higher-level hardware abstractions would be nice for everyone to have as well (quadrature rotary encoders, PWM, others).  For most IoT stuff, I don't need a true real-time OS as much as I need real security (ssh, SSL, CryptoPP, etc.), robust TCP/IP and a complete development environment without a huge investment.  And I much prefer a BSD license over GPL, which is one of the handful of reasons that FreeBSD remains my primary freenix target.


----------

