Re: [libgpiod] gpiomon loses events

[Maxim Devaev <mdevaev@xxxxxxxxx>]

> 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.

Well, it looks like something's wrong. Look, I took a Raspberry Pi 4
and libgpiod 1.5.2. Pin 13 receives a non-periodic signal. And here is
the result: https://gist.github.com/mdevaev/bcd6bb8e9c73383c88e410645c4d1797

Despite the fact that all event timestamps are increasing, I get a
large number of duplicate transitions without a reverse transition.
But the most important thing is the last line. I interrupted receiving
the signal, meaning the actual level at the end is 0. However, gpiomon
did not see this, and still believes that there is a 1. The reason for
this is that a single event on a line can contain up to 16 transition
events. However, the gpiomon tool and all python examples only read
the first event. I think this is a problem. I used the python sample
code in my project and was very surprised when my indicator showed the
1 state, but the actual state after the end of a series of events was
turned 0.

For the next example, I took the python implementation of gpiomon. The
git example behaves similarly to the C utility. I modified it as
follows: https://gist.github.com/mdevaev/70b9aa1505bd415167f3feb0e78e2f78
The result is: https://gist.github.com/mdevaev/776d8f8f600053fc42d019d92406641f

Here you can clearly see how several transition events are extracted
from a single line event. The timestamps are still consistently
increasing, however you still see several rising or falling without a
paired opposite event. Pay attention to the last 9 events. If I were
using a normal gpiomon at this point (which only reads the first event
on the line), I would skip the final falling. I see two problems here:
- The absence of the opposite pairs of events. I expected that for
every rising there should be a falling, but I don't see it. If that's
the way it should be, then fine. I admit, I didn't understand your
explanation about IRQ a bit, I'm sorry :)
- The second problem is that using the python example and the gpiomon
tool can lead to a desynchronization of understanding what state the
pin may actually be in. Both utilities should use
gpiod_line_event_read_multiple() instead of gpiod_line_event_read(),
as I think.

> It's how kfifo works, AFAIU it should rewrite first (older) ones.

In other words, it is the last transition event from a series of
events on the line that will reflect the current state of the pin,
right? Provided that there were no other events on the line.

пн, 14 сент. 2020 г. в 18:55, 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