Date: Tue, 24 Nov 2020 17:45:44 -0300 From: "Dr. Rolf Jansen" <freebsd-rj@obsigna.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: User Space GPIO Interrupt programming - GSoC-2018 Message-ID: <2126F3C0-D877-4483-9041-9FC84B9C8D3E@obsigna.com> In-Reply-To: <b4deea7dbe1f6890bf81357b3afd74561588bb76.camel@freebsd.org> References: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> <b4deea7dbe1f6890bf81357b3afd74561588bb76.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 24.11.2020 um 17:32 schrieb Ian Lepore <ian@freebsd.org>: >=20 > On Tue, 2020-11-24 at 17:14 -0300, Dr. Rolf Jansen wrote: >> Hello >>=20 >> Has anything of the GSoC-2018 efforts made it into the current code >> base? >>=20 >>=20 > = https://wiki.freebsd.org/SummerOfCode2018Projects/UserSpaceGPIOinterrupts >>=20 >> 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. >>=20 >> Perhaps I need to pull the project=E2=80=99s changes into the kernel = by >> myself. However, before this I would like to ask whether it is worth >> the effort. >>=20 >> Please, can anyone shed some light on this. >>=20 >> Best regards >>=20 >> Rolf >>=20 >=20 > 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=20 > code or what). >=20 > 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)? >=20 > 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2126F3C0-D877-4483-9041-9FC84B9C8D3E>