User Space GPIO Interrupt programming - GSoC-2018

[Warner Losh]

On Mon, Nov 30, 2020 at 2:52 PM Ian Lepore <ian at freebsd.org> wrote:

> On Fri, 2020-11-27 at 19:45 -0300, Dr. Rolf Jansen wrote:
> > Am 27.11.2020 um 15:04 schrieb Ian Lepore <ian at freebsd.org>:
> > > On Fri, 2020-11-27 at 10:16 -0700, Ian Lepore wrote:
> > > > On Fri, 2020-11-27 at 14:28 +0300, Vladimir Goncharov wrote:
> > > > > Here it is.
> > > > > There is struct gpioc_event with pin number and bintime which
> > > > > is send
> > > > > to userspace.
> > > > >
> > > > > Also I'm thinking about to implementation notofication without
> > > > > extra
> > > > > reading from socket via struct kevent's extra fields
> > > > > (fflags/ext[4]),
> > > > > looks like it is possible.
> > > > >
> > > >
> > > > Please don't top-post on freebsd mailing lists.
> > > >
> > > > I think we need a way for the app to choose whether it wants
> > > > simple
> > > > reporting of pin number (like the original code) perhaps along
> > > > with a
> > > > count, versus requesting detailed per-event data.  I'm going to
> > > > propose
> > > > something more detailed about this as soon as I get my thoughts
> > > > all
> > > > organized.  I also want to get the original code and the locking
> > > > fixes
> > > > I've done to it into a phab review for people to start looking at
> > > > before starting to do new major changes to it.
> > > >
> > > > Allocating memory in the interrupt handler isn't a good idea, it
> > > > will
> > > > just increase latency on processing other pin interrupts and lead
> > > > to
> > > > inaccurate timestamps.  IMO, it would be better to allocate a
> > > > fixed
> > > > array of events; when the app requests detailed event reporting
> > > > it can
> > > > request the number of stored events it wants handled and we could
> > > > allocate all at once based on that.
> > > >
> > >
> > > The gsoc2018 code, with locking and style(9) fixes, is now at:
> > >
> > >  https://reviews.freebsd.org/D27398
> >
> > I got it working, and as expected, by your comments the level
> > interrupt mode has been disabled. I am OK with this. Later, I will
> > add more comments on this in my response to you other e-mail.
> >
> > Best regards
> >
> > Rolf
>
> 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.
>

Well, ignoring leapseconds don't you mean? :)

But I think this is an acceptable limitation...

Well done in getting the cob webs dusted off this code and subsequent
tweaks...

Warner