Reading current output value

Reading current output value

[Yegor Yefremov]

On a am335x based board I have a GPIO pin that enables/disables power
of an external device (the bootloader sets this pin to output and 1,
and the kernel is instructed to not change it). Using kernel
5.19.0-rc2 and sysfs interface, I can read the current status as
follows:

echo 68 > /sys/class/gpio/export
cat /sys/class/gpio/gpio68/value

As a result, I read 1.

Using gpioget (libgpiod) v1.6.3, the line will be configured to
"input" and the value is set to 0:

# gpioget 2 4
0

So, how can I read the state without changing it? I am mostly
interested in using the kernel userspace API directly.

By the way, setting pin to 0 works but not to 1:

gpioset 2 4=0 - OK
gpioset 2 4=1 - no level change

sysfs works.

Regards,
Yegor

Re: Reading current output value

[Kent Gibson]

On Wed, Jun 22, 2022 at 09:54:41AM +0200, Yegor Yefremov wrote:
> On a am335x based board I have a GPIO pin that enables/disables power
> of an external device (the bootloader sets this pin to output and 1,
> and the kernel is instructed to not change it). Using kernel
> 5.19.0-rc2 and sysfs interface, I can read the current status as
> follows:
> 
> echo 68 > /sys/class/gpio/export
> cat /sys/class/gpio/gpio68/value
> 
> As a result, I read 1.
> 
> Using gpioget (libgpiod) v1.6.3, the line will be configured to
> "input" and the value is set to 0:
> 
> # gpioget 2 4
> 0
> 
> So, how can I read the state without changing it? I am mostly
> interested in using the kernel userspace API directly.
> 

The API itself supports it, but it isn't exposed in gpioget v1.6.3.
The gpioget in libgpiod master has a --dir-as-is option for exactly
this case, but that hasn't made its way into a libgpiod release yet.
(commit 3a912fbc1e2 tools: gpioget: add new --dir-as-is option for GPO read-back)
Can you try master?

> By the way, setting pin to 0 works but not to 1:
> 
> gpioset 2 4=0 - OK
> gpioset 2 4=1 - no level change
> 

gpioset has to remain running to guarantee the output level.
The pin is probably reverting when gpioset exits.
Try the --mode=wait option.

> sysfs works.
> 

Yes and no.

Cheers,
Kent.

Re: Reading current output value

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 12:32 PM Kent Gibson <warthog618@gmail.com> wrote:
> On Wed, Jun 22, 2022 at 09:54:41AM +0200, Yegor Yefremov wrote:

...

> > sysfs works.
>
> Yes and no.

Exactly, and I would suggest forgetting about sysfs. Consider it abandoned.

-- 
With Best Regards,
Andy Shevchenko

Re: Reading current output value

[Yegor Yefremov]

Hi Kent,

On Wed, Jun 22, 2022 at 12:26 PM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Wed, Jun 22, 2022 at 09:54:41AM +0200, Yegor Yefremov wrote:
> > On a am335x based board I have a GPIO pin that enables/disables power
> > of an external device (the bootloader sets this pin to output and 1,
> > and the kernel is instructed to not change it). Using kernel
> > 5.19.0-rc2 and sysfs interface, I can read the current status as
> > follows:
> >
> > echo 68 > /sys/class/gpio/export
> > cat /sys/class/gpio/gpio68/value
> >
> > As a result, I read 1.
> >
> > Using gpioget (libgpiod) v1.6.3, the line will be configured to
> > "input" and the value is set to 0:
> >
> > # gpioget 2 4
> > 0
> >
> > So, how can I read the state without changing it? I am mostly
> > interested in using the kernel userspace API directly.
> >
>
> The API itself supports it, but it isn't exposed in gpioget v1.6.3.
> The gpioget in libgpiod master has a --dir-as-is option for exactly
> this case, but that hasn't made its way into a libgpiod release yet.
> (commit 3a912fbc1e2 tools: gpioget: add new --dir-as-is option for GPO read-back)
> Can you try master?

# gpioget -v
gpioget (libgpiod) v2.0-devel
Copyright (C) 2017-2018 Bartosz Golaszewski
License: LGPLv2.1
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Now, I get my "1", but as soon as gpioget exits, the pin goes at "0".

> > By the way, setting pin to 0 works but not to 1:
> > gpioset 2 4=0 - OK
> > gpioset 2 4=1 - no level change
> >
>
> gpioset has to remain running to guarantee the output level.
> The pin is probably reverting when gpioset exits.
> Try the --mode=wait option.

Yes, this works, as long as gpioset is running.

Yegor

Re: Reading current output value

[Kent Gibson]

On Mon, Jun 27, 2022 at 12:37:46PM +0200, Yegor Yefremov wrote:
> Hi Kent,
> 
> On Wed, Jun 22, 2022 at 12:26 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Wed, Jun 22, 2022 at 09:54:41AM +0200, Yegor Yefremov wrote:
> > > On a am335x based board I have a GPIO pin that enables/disables power
> > > of an external device (the bootloader sets this pin to output and 1,
> > > and the kernel is instructed to not change it). Using kernel
> > > 5.19.0-rc2 and sysfs interface, I can read the current status as
> > > follows:
> > >
> > > echo 68 > /sys/class/gpio/export
> > > cat /sys/class/gpio/gpio68/value
> > >
> > > As a result, I read 1.
> > >
> > > Using gpioget (libgpiod) v1.6.3, the line will be configured to
> > > "input" and the value is set to 0:
> > >
> > > # gpioget 2 4
> > > 0
> > >
> > > So, how can I read the state without changing it? I am mostly
> > > interested in using the kernel userspace API directly.
> > >
> >
> > The API itself supports it, but it isn't exposed in gpioget v1.6.3.
> > The gpioget in libgpiod master has a --dir-as-is option for exactly
> > this case, but that hasn't made its way into a libgpiod release yet.
> > (commit 3a912fbc1e2 tools: gpioget: add new --dir-as-is option for GPO read-back)
> > Can you try master?
> 
> # gpioget -v
> gpioget (libgpiod) v2.0-devel
> Copyright (C) 2017-2018 Bartosz Golaszewski
> License: LGPLv2.1
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Now, I get my "1", but as soon as gpioget exits, the pin goes at "0".
> 

Is that line the only line used (i.e. exported) on that chip?
If that is the case, can you request another unused line first (e.g.
using gpiomon in the background, or, and only since you've already
mentioned sysfs, exporting using sysfs), then try the gpioget?


But fundamentally what you are trying to do is use the GPIO line as a
persistent store, which it is not.  The state of a GPIO line is
uncontrolled, and considered undefined, unless the line is requested
(exported to use the sysfs terminology).
The gpio tools have no option but to release the line when they exit,
and so can't be guaranteed to do what you want here.
It may work or, as you have found, it might not.

What you need is a userspace entity to request and hold the line and
be the ultimate arbiter of the state of the line.  The initial state of
the line could still be read from the line itself, though that should be
a last resort.  You mention your bootloader is configured to
initialise the line to 1, so you could take that as a given and have
the arbiter set it to 1 on startup.
I'm currently working on an update of gpioset for libgpiod v2 [1] that
has an interactive mode, so you can set the line and then control the
value later.
 e.g. gpioset --interactive --chip 2 4=1

Would that work for you?

Cheers,
Kent.

[1] https://lore.kernel.org/linux-gpio/20220627134447.81927-1-warthog618@gmail.com/

Re: Reading current output value

[Kent Gibson]

On Tue, Jun 28, 2022 at 12:52:53PM +0800, Kent Gibson wrote:
> On Mon, Jun 27, 2022 at 12:37:46PM +0200, Yegor Yefremov wrote:
> > Hi Kent,
> > 
> > On Wed, Jun 22, 2022 at 12:26 PM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > On Wed, Jun 22, 2022 at 09:54:41AM +0200, Yegor Yefremov wrote:
> > > > On a am335x based board I have a GPIO pin that enables/disables power
> > > > of an external device (the bootloader sets this pin to output and 1,
> > > > and the kernel is instructed to not change it). Using kernel
> > > > 5.19.0-rc2 and sysfs interface, I can read the current status as
> > > > follows:
> > > >
> > > > echo 68 > /sys/class/gpio/export
> > > > cat /sys/class/gpio/gpio68/value
> > > >
> > > > As a result, I read 1.
> > > >
> > > > Using gpioget (libgpiod) v1.6.3, the line will be configured to
> > > > "input" and the value is set to 0:
> > > >
> > > > # gpioget 2 4
> > > > 0
> > > >
> > > > So, how can I read the state without changing it? I am mostly
> > > > interested in using the kernel userspace API directly.
> > > >
> > >
> > > The API itself supports it, but it isn't exposed in gpioget v1.6.3.
> > > The gpioget in libgpiod master has a --dir-as-is option for exactly
> > > this case, but that hasn't made its way into a libgpiod release yet.
> > > (commit 3a912fbc1e2 tools: gpioget: add new --dir-as-is option for GPO read-back)
> > > Can you try master?
> > 
> > # gpioget -v
> > gpioget (libgpiod) v2.0-devel
> > Copyright (C) 2017-2018 Bartosz Golaszewski
> > License: LGPLv2.1
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> > 
> > Now, I get my "1", but as soon as gpioget exits, the pin goes at "0".
> > 
> 
> Is that line the only line used (i.e. exported) on that chip?
> If that is the case, can you request another unused line first (e.g.
> using gpiomon in the background, or, and only since you've already
> mentioned sysfs, exporting using sysfs), then try the gpioget?
> 

Just to expand on that a little, when the GPIO subsystem is finished
with a chip, so it no longer has any lines requested, it calls free on
the device driver.  What happens then depends on the device driver.
In this case the device driver (I'm assuming gpio-omap.c is the driver
for your am335x) reverts all the GPIO lines to inputs.

Any libgpiod tool will request the chip and then on exit, as no lines are
requested, the chip will be freed - resulting in what you are seeing.
Btw, the same would occur in you exported and unexported a line via sysfs.

Hence the suggestion to request/export a line to prevent the chip being
freed.  Or to switch to an approach where you hold the line and don't
release it.

Neither libgpiod nor the kernel gpio subsystem are explicitly requesting
a change to the line - it is an unfortunate quirk of the GPIO chip
driver interface.

I hope that helps.

Cheers,
Kent.

Re: Reading current output value

[Yegor Yefremov]

Hi Kent,

On Wed, Jun 29, 2022 at 4:14 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Tue, Jun 28, 2022 at 12:52:53PM +0800, Kent Gibson wrote:
> > On Mon, Jun 27, 2022 at 12:37:46PM +0200, Yegor Yefremov wrote:
> > > Hi Kent,
> > >
> > > On Wed, Jun 22, 2022 at 12:26 PM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > On Wed, Jun 22, 2022 at 09:54:41AM +0200, Yegor Yefremov wrote:
> > > > > On a am335x based board I have a GPIO pin that enables/disables power
> > > > > of an external device (the bootloader sets this pin to output and 1,
> > > > > and the kernel is instructed to not change it). Using kernel
> > > > > 5.19.0-rc2 and sysfs interface, I can read the current status as
> > > > > follows:
> > > > >
> > > > > echo 68 > /sys/class/gpio/export
> > > > > cat /sys/class/gpio/gpio68/value
> > > > >
> > > > > As a result, I read 1.
> > > > >
> > > > > Using gpioget (libgpiod) v1.6.3, the line will be configured to
> > > > > "input" and the value is set to 0:
> > > > >
> > > > > # gpioget 2 4
> > > > > 0
> > > > >
> > > > > So, how can I read the state without changing it? I am mostly
> > > > > interested in using the kernel userspace API directly.
> > > > >
> > > >
> > > > The API itself supports it, but it isn't exposed in gpioget v1.6.3.
> > > > The gpioget in libgpiod master has a --dir-as-is option for exactly
> > > > this case, but that hasn't made its way into a libgpiod release yet.
> > > > (commit 3a912fbc1e2 tools: gpioget: add new --dir-as-is option for GPO read-back)
> > > > Can you try master?
> > >
> > > # gpioget -v
> > > gpioget (libgpiod) v2.0-devel
> > > Copyright (C) 2017-2018 Bartosz Golaszewski
> > > License: LGPLv2.1
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.
> > >
> > > Now, I get my "1", but as soon as gpioget exits, the pin goes at "0".
> > >
> >
> > Is that line the only line used (i.e. exported) on that chip?
> > If that is the case, can you request another unused line first (e.g.
> > using gpiomon in the background, or, and only since you've already
> > mentioned sysfs, exporting using sysfs), then try the gpioget?
> >
>
> Just to expand on that a little, when the GPIO subsystem is finished
> with a chip, so it no longer has any lines requested, it calls free on
> the device driver.  What happens then depends on the device driver.
> In this case the device driver (I'm assuming gpio-omap.c is the driver
> for your am335x) reverts all the GPIO lines to inputs.
>
> Any libgpiod tool will request the chip and then on exit, as no lines are
> requested, the chip will be freed - resulting in what you are seeing.
> Btw, the same would occur in you exported and unexported a line via sysfs.
>
> Hence the suggestion to request/export a line to prevent the chip being
> freed.  Or to switch to an approach where you hold the line and don't
> release it.
>
> Neither libgpiod nor the kernel gpio subsystem are explicitly requesting
> a change to the line - it is an unfortunate quirk of the GPIO chip
> driver interface.
>
> I hope that helps.

Thanks for your thorough explanations. I see your point and the
similarity with sysfs export/unexport semantics.

So inputs are no problem and some real physical GPIOs can be handled
this way as well.

The only thing that I'd like to handle differently would be our mPCIe
VCC enable pin. It has a function of a regulator. AFAIK, the best way
is to use a userspace-consumer driver [1] like described here [2]. As
there is still no support for such a regulator in Device Tree, one
needs a dummy device as a consumer. So far, I couldn't find a suitable
example describing the whole setup. Do you have an idea how to
implement this function?

[1] https://www.kernel.org/doc/html/latest/power/regulator/consumer.html
[2] https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/regulator-userspace-consumer/ta-p/1389948

Yegor

Re: Reading current output value

[Kent Gibson]

On Wed, Jun 29, 2022 at 09:50:54AM +0200, Yegor Yefremov wrote:
> Hi Kent,
> 
> On Wed, Jun 29, 2022 at 4:14 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Tue, Jun 28, 2022 at 12:52:53PM +0800, Kent Gibson wrote:
> > > On Mon, Jun 27, 2022 at 12:37:46PM +0200, Yegor Yefremov wrote:
> > > > Hi Kent,
> > > >
> > > > On Wed, Jun 22, 2022 at 12:26 PM Kent Gibson <warthog618@gmail.com> wrote:
> > > > >
> > > > > On Wed, Jun 22, 2022 at 09:54:41AM +0200, Yegor Yefremov wrote:
> > > > > > On a am335x based board I have a GPIO pin that enables/disables power
> > > > > > of an external device (the bootloader sets this pin to output and 1,
> > > > > > and the kernel is instructed to not change it). Using kernel
> > > > > > 5.19.0-rc2 and sysfs interface, I can read the current status as
> > > > > > follows:
> > > > > >
> > > > > > echo 68 > /sys/class/gpio/export
> > > > > > cat /sys/class/gpio/gpio68/value
> > > > > >
> > > > > > As a result, I read 1.
> > > > > >
> > > > > > Using gpioget (libgpiod) v1.6.3, the line will be configured to
> > > > > > "input" and the value is set to 0:
> > > > > >
> > > > > > # gpioget 2 4
> > > > > > 0
> > > > > >
> > > > > > So, how can I read the state without changing it? I am mostly
> > > > > > interested in using the kernel userspace API directly.
> > > > > >
> > > > >
> > > > > The API itself supports it, but it isn't exposed in gpioget v1.6.3.
> > > > > The gpioget in libgpiod master has a --dir-as-is option for exactly
> > > > > this case, but that hasn't made its way into a libgpiod release yet.
> > > > > (commit 3a912fbc1e2 tools: gpioget: add new --dir-as-is option for GPO read-back)
> > > > > Can you try master?
> > > >
> > > > # gpioget -v
> > > > gpioget (libgpiod) v2.0-devel
> > > > Copyright (C) 2017-2018 Bartosz Golaszewski
> > > > License: LGPLv2.1
> > > > This is free software: you are free to change and redistribute it.
> > > > There is NO WARRANTY, to the extent permitted by law.
> > > >
> > > > Now, I get my "1", but as soon as gpioget exits, the pin goes at "0".
> > > >
> > >
> > > Is that line the only line used (i.e. exported) on that chip?
> > > If that is the case, can you request another unused line first (e.g.
> > > using gpiomon in the background, or, and only since you've already
> > > mentioned sysfs, exporting using sysfs), then try the gpioget?
> > >
> >
> > Just to expand on that a little, when the GPIO subsystem is finished
> > with a chip, so it no longer has any lines requested, it calls free on
> > the device driver.  What happens then depends on the device driver.
> > In this case the device driver (I'm assuming gpio-omap.c is the driver
> > for your am335x) reverts all the GPIO lines to inputs.
> >
> > Any libgpiod tool will request the chip and then on exit, as no lines are
> > requested, the chip will be freed - resulting in what you are seeing.
> > Btw, the same would occur in you exported and unexported a line via sysfs.
> >
> > Hence the suggestion to request/export a line to prevent the chip being
> > freed.  Or to switch to an approach where you hold the line and don't
> > release it.
> >
> > Neither libgpiod nor the kernel gpio subsystem are explicitly requesting
> > a change to the line - it is an unfortunate quirk of the GPIO chip
> > driver interface.
> >
> > I hope that helps.
> 
> Thanks for your thorough explanations. I see your point and the
> similarity with sysfs export/unexport semantics.
> 
> So inputs are no problem and some real physical GPIOs can be handled
> this way as well.
> 
> The only thing that I'd like to handle differently would be our mPCIe
> VCC enable pin. It has a function of a regulator. AFAIK, the best way
> is to use a userspace-consumer driver [1] like described here [2]. As
> there is still no support for such a regulator in Device Tree, one
> needs a dummy device as a consumer. So far, I couldn't find a suitable
> example describing the whole setup. Do you have an idea how to
> implement this function?
> 

Sorry outside my domain.

But if it is just the enable pin you need to control and the pin is
accessible to the GPIO subsystem then you can control it like any
other GPIO line.

That might not give you any of the advantages of integrating with the
voltage and current regulator framework, but it could get your lights
on.

Cheers,
Kent.