Re: [libgpiod] gpiomon loses events

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

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.

> 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