Re: User Space GPIO Interrupt programming - GSoC-2018

"Dr. Rolf Jansen" <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
> Am 24.11.2020 um 17:32 schrieb Ian Lepore <[email protected]>:
> 
> 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

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.