User Space GPIO Interrupt programming - GSoC-2018

[Ian Lepore]

On Tue, 2020-12-01 at 02:15 -0300, Dr. Rolf Jansen wrote:
> Am 30.11.2020 um 18:52 schrieb Ian Lepore <ian at freebsd.org>:
> > [...]
> > I've just updated the phabricator review with new code.  This adds
> > the
> > detailed versus summary reporting.  I decided the detailed
> > reporting
> > should still be the default like it was before, but now it can
> > handle
> > many events between calls to read(), unlike the old code that only
> > stored one pin change event between calls.  Now it uses a circular
> > buffer, and there's a new ioctl function for increasing the size of
> > the
> > buffer (or switching to summary reporting mode).
> > 
> > I incorporated Christian's test program into the phab review, and
> > added
> > some enhancements to it.  It shows how to read and interpret the
> > new
> > detailed and summary structures, how to convert the monotonic clock
> > event timestaps to UTC if needed (*), and how to handle getting
> > multiple event notifications with each read() call (by passing a
> > big
> > buffer and parsing the structs from it after the call).
> > 
> >  https://reviews.freebsd.org/D27398
> > 
> > (*) The conversion of monotonic to utc time doesn't attempt to deal
> > with the system clock being stepped between the time an event was
> > recorded and when it is printed.  In the real world, system time
> > gets
> > stepped when the system boots, not at random while apps are
> > running.
> > 
> > -- Ian
> 
> I just tested it, by utilizing the gpioevent test tool. And
> everything is working exactly the way, I need it. For example, on the
> BBB, I connected a quite worn-out push button to a GPIO in PU mode
> and to DGND. This button is known to bounce heavily. Now with your
> enhancements and the new tool which reports the timestamps, I could
> do debouncing in software.
> 
> gpioevents -f /dev/gpioc2 -m r 3 er
> 
> Again this is a really bad button, however the BBB seems to be able
> to pick up the bounces in less than a ms resolution. I don’t need
> more.
> 
> Press:
> time 1122.784614858 pin 3 state 1
> [...]
> time 1122.793768903 pin 3 state 1
> time 1122.794032353 pin 3 state 1
> time 1122.797496036 pin 3 state 1
> time 1122.797512911 pin 3 state 1
> 
> Release
> time 1122.933694459 pin 3 state 1
> time 1122.933713000 pin 3 state 1
> time 1122.933749748 pin 3 state 1
> 
> What is the expected significant time resolution. 9 digits suggests
> that it is nanoseconds, however, I tend to believe, that it is
> perhaps microseconds (6 digits after the dp), isn’t it?
> 
> Please let me know, if you want me to test anything else.
> 
> Please inform me once all this becomes committed to head, then I can
> remove the patched files and svn-update the sources for the custom
> kernel.
> 
> Thank you very much.
> 
> Best regards
> 
> Rolf

In my testing on an imx6 (1ghz 4-core) I fed it a 10mhz square wave,
told it to watch for either edge, and was getting an event every 10
microseconds or so.  It does a little better if you're only watching
for rising or falling edge, about every 6-7us, because in that case it
doesn't have to make an extra call to sample the state of the gpio pin
in the interrupt handler.

I think the code is ready to commit as soon as the review gets some
approval feedback.  The one thing that remains to be done is to write a
gpioc(4) manpage documenting all this stuff, which I intend to do some
time in the next week or two, but I don't think I need to hold up the
commit for that.

-- Ian