Re: User Space GPIO Interrupt programming - GSoC-2018

On Fri, 2020-11-27 at 19:45 -0300, Dr. Rolf Jansen wrote:
> Am 27.11.2020 um 15:04 schrieb Ian Lepore <[email protected]>:
> > 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.

-- Ian


_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"