Date: Mon, 30 Nov 2020 15:46:32 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: "Dr. Rolf Jansen" <freebsd-rj@obsigna.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: User Space GPIO Interrupt programming - GSoC-2018 Message-ID: <CANCZdfpUN9TiJJ1h=U%2BFByCG=d9mhFigjV_wKX51Zo=g5OSV6Q@mail.gmail.com> In-Reply-To: <af7527d32fcfbf5a7e09bdf6eda9467ce1342639.camel@freebsd.org> References: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> <c55d7f332631b69c3241a60538a6a7b5475d93b9.camel@freebsd.org> <FBEF19B1-0504-4CDF-976C-C50707E06584@obsigna.com> <8d806302-479c-ca34-3fdb-96d27f40e212@viruzzz.org> <8655AF30-273B-48E7-98CD-007AA1D265F5@obsigna.com> <54ffe2d2-01a2-8b43-94fa-aee4a3f89861@viruzzz.org> <08649892ca2ab434c261d36e0e13ba051086de6f.camel@freebsd.org> <1e6993d43d22d6ce1aa2860a61745356688d1e53.camel@freebsd.org> <BD08359D-C61D-454F-95A1-92B248707B9C@obsigna.com> <af7527d32fcfbf5a7e09bdf6eda9467ce1342639.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 30, 2020 at 2:52 PM Ian Lepore <ian@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpUN9TiJJ1h=U%2BFByCG=d9mhFigjV_wKX51Zo=g5OSV6Q>