Re: Regarding export of GPIOs

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

 



On Tue, Aug 31, 2021 at 08:38:01PM +0530, Riz wrote:
> Sorry the kernel log was:
> [    0.251788] GPIO line <num> (name) hogged as output/low
> 

It is a bit of a worry that you are editing logs, rather than just
copying them verbatim.  That is just another source of error and
confusion.
The only info you would be leaking here are the num and name, and neither
are significant.
If you are still concerned you can always make the name in your dts
something anonymous but still more meaningful than "name".
Call it "foobar" or something.

> Regards.
> 
> On Tue, Aug 31, 2021 at 8:35 PM Riz <mdrizwan827@xxxxxxxxx> wrote:
> >
> > Hi Kent,
> > Thank you for your response.
> >
> > I am observing a strange thing here.
> >
> > The kernel logs for the hogged GPIO reports as:
> > [    0.251788] GPIO line <num> (name) hogged as output/high
> >
> > The corresponding dts changes are:
> > >
> > > pNum {
> > > gpio-hog;
> > > gpios = <num GPIO_ACTIVE_LOW>;
> > > output-low;
> > > line-name = "name";
> > > };
> >

Just to re-iterate Andy's response - if you intend to make active use of
the line then hogging is not the way to go - it is for statically
setting lines for which no driver exists.

And setting GPIO_ACTIVE_LOW makes no sense in this context.  That inverts
the polarity when mapping between logical and physical values, but for
hogs you are not actively using the line so the logical value is not
relevant.
The output-low sets the physical level to low, and an output-high would
set it high.  No logical value involved.

The remainder of the response assumes you just want to determine why the
kernel is not reporting what you expect on a hogged line.

> >
> > Based on the kernel log, I could say that it is hogging the GPIO as expected.
> >
> > But using the gpioinfo and lsgpio tools always show the direction as
> > "input" for the hogged GPIO.
> > gpioinfo <chipname>:
> > line  X:      "pX" "name"   input   active-low [used]
> >
> > lsgpio -n <chipname>:
> > line X: "pX" "name" [kernel active-low]
> >

So lsgpio agrees with gpioinfo in that FLAG_IS_OUT is not set, and the
problem you are seeing is almost certainly on the kernel side.

> > I tried following the kernel by adding some logs, it seems to set the
> > correct direction.

To absolutely confirm that you could add debugging to the kernel to
report the desc->flags after the line is hogged, so in gpiod_hog(), and
where the info is read in gpiolib-cdev lineinfo_get() or
lineinfo_get_v1(), as appropriate.

If those differ then I would add debugging to all the places the
FLAG_IS_OUT is cleared to see if they are somehow being called and
clearing the flag after it is set by gpiod_hog().

If that doesn't turn up anything then the last resort is using a debugger
to put a hardware breakpoint on the desc->flags to identify how it is
being changed.

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