Re: Edit/gpiomon: Question about mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux