Re: Edit/gpiomon: Question about mode

[Hans Kurscheidt <lve0200@gmail.com>]

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"