User Space GPIO Interrupt programming - GSoC-2018

Dr. Rolf Jansen freebsd-rj at obsigna.com
Tue Nov 24 20:45:51 UTC 2020


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

I was asked to jump into a project where push buttons and pulses from a rotary encoder (all connected to GPIO's) would invoke some programmed actions. Polling the GPIO's would be too faulty. To me "pin-change notifications delivered to userland" sounds not too bad for my purpose. However, I won't say no for a real threaded GPIO interrupt handler facility, which presumably would serve perfectly as well.

Thank you for answering

Best regards

Rolf


More information about the freebsd-arm mailing list