GPIO pin is reset to default value after release.
Bills, Jason M
jason.m.bills at linux.intel.com
Thu Jan 7 08:57:11 AEDT 2021
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.
>
More information about the openbmc
mailing list