Re: GPIO pin is reset to default value after release.

["Bills, Jason M" <jason.m.bills@linux.intel.com>]

On 1/5/2021 6:14 PM, 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.
The approach that I have used is instead of treating the pin as a 
generic GPIO, treat it based on its function.

For example, if you have a GPIO that indicates something like a button 
press, instead of having a generic GPIO service that exposes that GPIO 
state on D-Bus, have a button service that exposes the state of that 
GPIO on D-Bus as the button state.

This can be easier to read from the D-Bus perspective and will let you 
keep the GPIO management in the applications that care about that GPIO.

Thanks,
-Jason

> 
> 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.
>