Date: Thu, 26 Nov 2020 22:18:22 -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: <FBEF19B1-0504-4CDF-976C-C50707E06584@obsigna.com> In-Reply-To: <c55d7f332631b69c3241a60538a6a7b5475d93b9.camel@freebsd.org> References: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> <c55d7f332631b69c3241a60538a6a7b5475d93b9.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 26.11.2020 um 16:56 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=C2=B4s 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 made some time this morning to review the gsoc2018 code. It turns > out this code is very high quality, nearly ready to commit as-is. The > main thing it needs is some style cleanup in its comment blocks, and > documentation. I'd be inclined to commit the code first and write the > documentation over the next little while and commit it separately. >=20 > If you'd like to give it a try, here's a diff that should apply and > build cleanly on freebsd 12 or 13: >=20 > https://people.freebsd.org/~ian/gpio_gsoc2018.diff >=20 > While there isn't any documentation yet, there is a test program (I > haven't run it yet) that demonstrates all the features: >=20 > = https://github.com/ckraemer/gsoc2018-utils/blob/master/src/gpioc_intr_test= .c >=20 > Right now the code will let you block waiting for a pin-change event > using select(), poll() or kevents, or to be notified via SIGIO, but > after being notified that something happened, you still have to call > read() to see which pin changed. I think if the pin changes state > multiple times between calls to read(), you'll lose track of some > changes (I'm not positive of that, I don't understand the kevent stuff > well). >=20 > I'd like to add some features so that you can configure it to track = pin > changes in counting-mode and timestamping-mode. In counting mode, = when > you do a read() you would get back a pair of values, the pin number = and > how many times its interrupt fired since the last read. In > timestamping mode, every read would return a pin number and an > associated timespec giving the exact time the interrupt happened = (there > would need to be a way to configure how many events it could buffer, > but I think even allowing a thousand buffered events would only use a > few kbytes of memory). I got it working as well, please see my other post from yesterday. I = used gpioc_intr_test.c. I see hundreds of warning messages when I press the test button a few = times. May these warnings be safely ignored. The kernel module of Oskar = Holmund works quite nice as well (for what I need), and with that one, I = don=E2=80=99t see warnings. The counting- and timestamping-mode for sure would be very useful. = Perhaps by implementing this, there won=E2=80=99t be no unhandled = interrupts anymore, and hence there won=E2=80=99t be any warnings = either. Best regards Rolf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FBEF19B1-0504-4CDF-976C-C50707E06584>