User Space GPIO Interrupt programming - GSoC-2018

[Dr. Rolf Jansen]

> Am 24.11.2020 um 17:32 schrieb Ian Lepore <ian at freebsd.org>:
> 
> On Tue, 2020-11-24 at 17:14 -0300, Dr. Rolf Jansen wrote:
>> Hello
>> 
>> Has anything of the GSoC-2018 efforts made it into the current code
>> base?
>> 
>> 
> https://wiki.freebsd.org/SummerOfCode2018Projects/UserSpaceGPIOinterrupts
>> 
>> I installed the recent 13.0-CURRENT snapshot (2020-11-19) on a
>> BeagleBone Black which was one of the implementation targets of said
>> project, but when running the test tools, I either see cannot
>> read/kevent/poll/aio_read - Operation not supported by device or
>> Inappropriate ioctl for device.
>> 
>> Perhaps I need to pull the project’s changes into the kernel by
>> myself. However, before this I would like to ask whether it is worth
>> the effort.
>> 
>> Please, can anyone shed some light on this.
>> 
>> Best regards
>> 
>> Rolf
>> 
> 
> I have had that webpage open (but docked) for literally a year,
> eternally hoping that I can find time to get to it and somehow get it
> committed, or maybe use it as the basis for something to be committed
> (I haven't even looked at it close enough to see if it's commit-quality 
> code or what).
> 
> I'm curious: What particular need do you have for userspace gpio
> interrupts?  What would you like the API to look like (do you like the
> things listed at that page, or would you prefer something else)?
> 
> Interrupts is probably not a good name, because it isn't really going
> to act like an interrupt does for kernel code.  It's really just pin-
> change notifications delivered to userland.

On the Forums somebody reported already success after patching his kernel with the GSoC-2018 diff's

https://forums.freebsd.org/threads/user-space-interface-for-gpio-interrupts.71005/post-428661

He even provided a patch file, and I simply applied this to the /base/head sources which I updated right before by svn update. Then I recompiled the kernel for the BBB, and guess what, it works.

For testing, I connected a push button to p8.2 and p8.14, and then on the command line:

# gpioctl -f /dev/gpioc0 -c 26 IN PU
# ./gpio_intr_test -f /dev/gpioc0 26 ll

Then every time when I push the button I see one line:

gpio_intr_test: read() interrupt on pin 26 of /dev/gpioc0

This looks quite promising. I would need to examine this test tool which is provided on the GSoC-2018 GitHub-repository, and then build the read() handler into my code. 

However, for as long as the button is pushed I see also ton's of the following warning messages in the serial console:

gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
gpioc0: Unhandled interrupt on pin 26.
...

When I run the test tool in er mode (edge rising), then I see only 2 warnings for each push in the serial console, but because the button is not debounced, I see a multitude of event messages by the test tool. The latter behaviour is actually great, since this means that the interrupts are handled very quick.

Anyway, how would I suppress the warning messages in the serial console?

Best regards

Rolf