Re: [libgpiod] gpiomon loses events

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

+Cc: libgpiod maintainers

On Mon, Sep 14, 2020 at 6:54 PM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
>
> On Mon, Sep 14, 2020 at 6:12 PM Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx> wrote:
> >
> > On Mon, Sep 14, 2020 at 1:40 PM Maxim Devaev <mdevaev@xxxxxxxxx> wrote:
> > >
> > > Hi. I noticed a strange behavior of gpiomon and gpiomon.py. It seems
> > > that in some cases, if the signal arrives at the GPIO pin too quickly,
> > > the last event on it may be rising, despite the fact that the actual
> > > signal is already set to 0.
> >
> > I'm not sure I understood what's wrong here. 'Event' by definition is
> > something that has already happened. If pin floats from 0 to 1 to 0
> > you will get one rising and one falling event.
> >
> > > a Cursory study of the sources showed that
> > > both of these utilities read only one (the first?) event from the
> > > line. I changed gpiomon.py rby replacing read_event() to
> > > read_event_multiply() and iterating by all events, and it looks like
> > > the lost faling events were there.
> > >
> > > So, I have a few questions.
> > >
> > > 1) Is this really a bug in gpiomon, or is it intended to be?
> > >
> > > 2) If I use read_events_multiple(), can it skip some events? I noticed
> > > that sometimes I can get several falling and rising in a row.
> > > Why is
> > > this happening?
> >
> > I can assume that IRQ handler is reentrant and since it has been run
> > in the thread we will get it messed up. The timestamp of the event
> > (when recorded) should be used for serialization of events. But if my
> > assumption is the case, we have to record it in a hard IRQ context.
>
> ...but this is exactly what we are doing in the latest code (didn't
> check from which kernel it's a default approach).
>
> So, do you have the timestamps not paired?
>
> > > Shouldn't they be paired? Can the state transition,
> > > i.e. the final falling or rising, be lost?
> > >
> > > 3) It seems there can only be 16 events in a line. What happens if
> > > more events occur in one iteration of the loop, such as 20? The last 4
> > > events will be lost, they will be available in the next iteration of
> > > event_wait(), or the first 4 events in the current iteration will be
> > > discarded?
> >
> > It's how kfifo works, AFAIU it should rewrite first (older) ones.
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
>
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
With Best Regards,
Andy Shevchenko