GPIO pin is reset to default value after release.

[Andrew Jeffery]

On Wed, 6 Jan 2021, at 12:44, Thu Nguyen wrote:
> On 1/6/21 08:12, Andrew Jeffery wrote:
> >
> > On Wed, 6 Jan 2021, at 02:57, Thu Nguyen wrote:
> >> Hi,
> >>
> >>
> >> Current I'm using two difference GPIO libs gpiod and gpioplus to setting
> >> GPIO pins.
> >>
> >> I can set the GPIO pin to expected value in a service. And GPIO keep
> >> unchanging when the service is running.
> >>
> >> But when the service is exited, the GPIO handler is released then GPIO
> >> is reset to default value.
> >>
> >>
> >> Do we have any gpio lib which don't reset the GPIO when the handler is
> >> released?
> > No. This is a property of the GPIO chardev interface provided by the kernel. libgpiod makes the kernel interface a bit nicer to consume in user space, but isn't where this behaviour is contracted (i.e. any use of the chardev interface might result in this behaviour, libgpiod or otherwise).
> >
> > At the moment the way to get the behaviour you desire is to keep the line handle open.
> 
> Yes, This is what I did at this moment to keep the GPIO pin unchanged.
> 
> But the GPIO pin will be locked and no service can read that GPIO pins 
> when is is locked.
> 
> >
> > The deprecated approach is to use the sysfs interface instead, but that's strongly discouraged.
> >
> > That said, your problem is something I have on my to-do list to address with upstream. I'll Cc the openbmc list whenever I get to it.
> 
> I thought about a GPIO service which will create DBus servers and Dbus 
> method to set/get/release the GPIO pins and keep that GPIO pin unchanged 
> until next setting.
> 
> That service will handle and keep the gpio line. All of others openBmc 
> services will access GPIO thru that service.

Bartosz (kernel GPIO / libgpiod maintainer) already has some half-baked code 
along these lines:

https://github.com/brgl/libgpiod/tree/topic/gpio-dbus

That said, it doesn't solve the problem of needing GPIO state to persist across 
reboots, as the moment the D-Bus daemon is killed the line state will revert.

I think it's desirable to solve it properly with some kernel trickery rather 
than using a daemon in userspace.

All this aside, Jason's approach of exposing the lines in terms of their 
purpose is also a good idea.

Andrew