Re: Edit/gpiomon: Question about mode

[Hans Kurscheidt <lve0200@gmail.com>]

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
>