GPIO pin is reset to default value after release.

[Thu Nguyen]

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.

It can use the same ways which phosphor-sel-logger do to provide 
xyz.openbmc_project.Logging.IPMI service and function IpmiSelAddOem.

>
> Cheers,
>
> Andrew

Cheers,

Thu Nguyen.