Re: Edit/gpiomon: Question about mode

[Kent Gibson <warthog618@xxxxxxxxx>]

On Tue, Mar 29, 2022 at 03:56:36PM +0200, Hans Kurscheidt wrote:
> 
> Am 29.03.2022 um 15:37 schrieb Hans Kurscheidt:
> > 
> > Am 29.03.2022 um 10:51 schrieb Kent Gibson:
> > > On Tue, Mar 29, 2022 at 10:43:19AM +0200, Hans Kurscheidt wrote:
> > > > Am 29.03.2022 um 10:38 schrieb Kent Gibson:
> > > > > On Tue, Mar 29, 2022 at 10:07:57AM +0200, Hans Kurscheidt wrote:
> > > > > > Am 29.03.2022 um 05:38 schrieb Kent Gibson:
> > > > > > > On Mon, Mar 28, 2022 at 07:13:13PM +0200, Hans Kurscheidt wrote:
> > > > > > > > Am 28.03.2022 um 15:16 schrieb Hans Kurscheidt:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > what would be the right mode for gpiomon call from
> > > > > > > > > 
> > > > > > > > > a shellscript executed as root from systemd at system start
> > > > > > > > > 
> > > > > > > > > waiting on a Pin w/ pullup for invoking
> > > > > > > > > shutdown upon rising* edge.
> > > > > > > > > *changed
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Lots of interupts, Signals and other GPIO
> > > > > > > > > ongoing from other user APPs &
> > > > > > > > > threads in multi-user state.
> > > > > > > > 2b more precise: I wired a GPIO Pin to GND.
> > > > > > > > 
> > > > > > > > Upon the cmd: sudo gpiomon -r -n1 <chip> <offset>
> > > > > > > > 
> > > > > > > > the program exits immediately with 1 event,
> > > > > > > > although there was never a
> > > > > > > > rising edge due to the fix wire to GND. Is this
> > > > > > > > a feature or a bug, and is
> > > > > > > > it reproducible?
> > > > > > > > 
> > > > > > > Not a feature and not reproducible for me on a
> > > > > > > Raspberry Pi4 with the
> > > > > > > setup you describe, so probably a bug specific to
> > > > > > > your hardware platform,
> > > > > > > whatever that may be.
> > > > > > > 
> > > > > > > If it is 100% reproduceable for you, and assuming it
> > > > > > > is an initialisation
> > > > > > > issue so you only get the one spurious event, how
> > > > > > > about using -n2 as a
> > > > > > > workaround ;-)?
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > Kent.
> > > > > > It appears 2b reproduceable 100% on my OrangePi zero+
> > > > > > (Allwinner H5) and
> > > > > > using -n2 does the trick, but isn't gpiod not supposed to work on all
> > > > > > commercial HW platforms and related kernels, rather then
> > > > > > only on RPI??
> > > > > > 
> > > > > gpiod will work on any platform with a supporting kernel.
> > > > > How well depends on the underlying hardware and driver.
> > > > > The RPi4 was merely a counter-example demonstrating that your issue is
> > > > > not universal, using hardware I happen to have readily available.
> > > > > 
> > > > > Cheers,
> > > > > Kent.
> > > > So if I understand you right, gpiod works on sort of a logical
> > > > level, while
> > > > the HW dependend part depends of the kernel driver
> > > > implementation of the
> > > > specific HW?
> > > > 
> > > > 
> > > libgpiod is a userspace library and tools to access GPIO lines via the
> > > Linux GPIO character device.  The actual interfacing to the hardware is
> > > performed by the kernel and appropriate drivers for your hardware.
> > > As your problem does not exhibit on other hardware, the root cause
> > > of your problem probably lies in the driver for your hardware, not in
> > > libgpiod nor the gpiolib subsystem of the kernel.
> > > 
> > > But you would need to debug it further to be sure.
> > > 
> > > Cheers,
> > > Kent.
> > 
> > I raised a bug report at tha Armbian forum:
> > 
> > https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/
> > 
> > 
> > 
> > I made some trial to understand if it is reproduceable, but I have
> > difficulties defining, when it happens. After RESET there is no spurious
> > event. The spurious event appears to happen, when the line was moved:
> > 
> > Could you please make another trial on your RPI w/ the following
> > sequence:
> > 
> > RESET, gpiomon -r -n1 -Bpull-up <chip><line>  => No event,  -> pull line
> > up /down, => event (as expected), gpiomon -r -n1 -Bpull-up <chip><line>
> > => false event
> > 
> > There might be an issue w/ pending interrupts, when the line is bouncing
> > when pulled up/down. The 2nd gpiodmon cmd might catch one of the pending
> > interrupts. (Just an idea). This would hint to an initialisation
> > problem, that pending line states are not preempted, before the int is
> > attached.
> > 
> sorry, 1 more thing,f I just let the line go up (by pull-up) and leave it
> "1", I get continuous false events on every gpiomon... cmd, just like "level
> interrupts"
> 
> 

And one more thing - your external pull-down has to be stronger
than the internal pull-up, else the two will will contend and leave your
line in a logical no man's land.  In my testing I pulled the line
directly to ground as I'm not sure how strong the internal pull-ups are
on the RPi and didn't want to expend time hunting for an appropriately
sized resistor anyway.

Cheers,
Kent.