gpiomon: Question about mode

gpiomon: Question about mode

[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 falling edge.


Lots of interupts, Signals and other GPIO ongoing from other user APPs & 
threads in multi-user state.

RGDS

hk

Edit/gpiomon: Question about mode

[Hans Kurscheidt]

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?

>
> RGDS
>
> hk
>
>

Re: Edit/gpiomon: Question about mode

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

Re: Edit/gpiomon: Question about mode

[Hans Kurscheidt]

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

RGDS

hk

Re: Edit/gpiomon: Question about mode

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

Re: Edit/gpiomon: Question about mode

[Hans Kurscheidt]

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?

Re: Edit/gpiomon: Question about mode

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

Re: Edit/gpiomon: Question about mode

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


OK, thank's. I'll raise a bug report for the OPI kernel guys in the 
ARMBIAN forum.

Re: Edit/gpiomon: Question about mode

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

Re: Edit/gpiomon: Question about mode

[Hans Kurscheidt]

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"

Re: Edit/gpiomon: Question about mode

[Kent Gibson]

On Tue, Mar 29, 2022 at 03:37:25PM +0200, Hans Kurscheidt wrote:
> 
> 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
> 

Not sure what this is intending to prove, as the hardware is different,
or is that the point?

That is with the line initially pulled down externally, right?
I get an event when I disconnect the external pull-down - allowing the
internal pull-up to pull the line high and trigger the event.

I don't get the false event that you are seeing subsequently, even when
the line has been externally pulled up before being pulled down again
and gpiomon run again.

i.e. I see
 - line externally pulled down
 - power cycle RESET
 - gpiomon -r -n1 -Bpull-up <chip><line>  => No event
 - disconnect pull-down => event (RISING edge)
 - pull line up (or not - optional due to internal pull-up)
 - pull line down again
 - gpiomon -r -n1 -Bpull-up <chip><line> => No event

And I don't get continuous events if the line is left pulled up - I only
get the one.
Do you get those continuous events with out the -n1, or only when
calling gpiomon -n1 again?
Either way it looks like you've got something odd going on with the
interrupts on your hardware.

Cheers,
Kent.

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

Re: Edit/gpiomon: Question about mode

[Kent Gibson]

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.

Re: Edit/gpiomon: Question about mode

[Hans Kurscheidt]

Am 29.03.2022 um 17:25 schrieb Kent Gibson:
> 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.
That's what i did, I used a patch wire directly from the GPIO pin to  
the GND Pin
>