GPIO pin is reset to default value after release.

GPIO pin is reset to default value after release.

[Thu Nguyen]

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?


Thanks.

Thu Nguyen.

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

[Vijay Khemka]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Tue, Jan 5, 2021 at 8:29 AM Thu Nguyen <thu@amperemail.onmicrosoft.com>
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.
>

Can you make service "run always". systemd service allows this.

>
>
> Do we have any gpio lib which don't reset the GPIO when the handler is
> released?
>
>
> Thanks.
>
> Thu Nguyen.
>
>

[-- Attachment #2: Type: text/html, Size: 1158 bytes --]

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

[Andrew Jeffery]

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.

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.

Cheers,

Andrew

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

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

[Bills, Jason M]

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

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

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Wed, Jan 06, 2021 at 11:42:26AM +1030, Andrew Jeffery wrote:
> > 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.
> 
> 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.

Glad you're looking to fix this.

I'm sure you are already aware but this makes usage value of libgpiod pretty
low for a lot of BMC function.  There are many cases where we need to preserve
GPIO state even through a BMC reset, but certainly in the event that the app
holding the GPIO crashed.  If we don't retain the state adverse side-effects
happen to the host.

I had a similar issue on the last non-BMC embedded device I worked on as well
and we couldn't use libgpiod as a result.  It is unfortunate the current
state of affairs because officially the sysfs gpio interfaces were
suppose to be removed last year.

https://github.com/torvalds/linux/commit/fe95046e960b4b76e73dc1486955d93f47276134

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 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