Date: Fri, 27 Nov 2020 11:02:56 +0300 From: Vladimir Goncharov <freebsd@viruzzz.org> To: freebsd-arm@freebsd.org Subject: Re: User Space GPIO Interrupt programming - GSoC-2018 Message-ID: <8d806302-479c-ca34-3fdb-96d27f40e212@viruzzz.org> In-Reply-To: <FBEF19B1-0504-4CDF-976C-C50707E06584@obsigna.com> References: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> <c55d7f332631b69c3241a60538a6a7b5475d93b9.camel@freebsd.org> <FBEF19B1-0504-4CDF-976C-C50707E06584@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Rolf, I have implemented in kernel queue for generated GPIO interrupts with timestamps, so now it's possible to catch all events even on busy system. It's all for gpio_gsoc2018 code. In result I have no more warnings in dmesg. Unfortunately it requires allocating memory on each event to store pin number and timestamp. In case of unability allocating memory it falls back to gpio_gsoc2018 method. Does anybody interested in such patches? 2020-11-27 04:18, Dr. Rolf Jansen пишет: >> Am 26.11.2020 um 16:56 schrieb Ian Lepore <ian@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 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. >> >> If you'd like to give it a try, here's a diff that should apply and >> build cleanly on freebsd 12 or 13: >> >> https://people.freebsd.org/~ian/gpio_gsoc2018.diff >> >> While there isn't any documentation yet, there is a test program (I >> haven't run it yet) that demonstrates all the features: >> >> https://github.com/ckraemer/gsoc2018-utils/blob/master/src/gpioc_intr_test.c >> >> 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). >> >> 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’t see warnings. > > The counting- and timestamping-mode for sure would be very useful. Perhaps by implementing this, there won’t be no unhandled interrupts anymore, and hence there won’t be any warnings either. > > Best regards > > Rolf > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8d806302-479c-ca34-3fdb-96d27f40e212>