* GPIO pin is reset to default value after release. @ 2021-01-05 16:27 Thu Nguyen 2021-01-05 17:21 ` Vijay Khemka 2021-01-06 1:12 ` Andrew Jeffery 0 siblings, 2 replies; 7+ messages in thread From: Thu Nguyen @ 2021-01-05 16:27 UTC (permalink / raw) To: openbmc 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GPIO pin is reset to default value after release. 2021-01-05 16:27 GPIO pin is reset to default value after release Thu Nguyen @ 2021-01-05 17:21 ` Vijay Khemka 2021-01-06 1:12 ` Andrew Jeffery 1 sibling, 0 replies; 7+ messages in thread From: Vijay Khemka @ 2021-01-05 17:21 UTC (permalink / raw) To: Thu Nguyen; +Cc: openbmc [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GPIO pin is reset to default value after release. 2021-01-05 16:27 GPIO pin is reset to default value after release Thu Nguyen 2021-01-05 17:21 ` Vijay Khemka @ 2021-01-06 1:12 ` Andrew Jeffery 2021-01-06 2:14 ` Thu Nguyen 2021-01-07 17:03 ` Patrick Williams 1 sibling, 2 replies; 7+ messages in thread From: Andrew Jeffery @ 2021-01-06 1:12 UTC (permalink / raw) To: openbmc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GPIO pin is reset to default value after release. 2021-01-06 1:12 ` Andrew Jeffery @ 2021-01-06 2:14 ` Thu Nguyen 2021-01-06 21:57 ` Bills, Jason M 2021-01-10 23:57 ` Andrew Jeffery 2021-01-07 17:03 ` Patrick Williams 1 sibling, 2 replies; 7+ messages in thread From: Thu Nguyen @ 2021-01-06 2:14 UTC (permalink / raw) To: Andrew Jeffery, openbmc 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GPIO pin is reset to default value after release. 2021-01-06 2:14 ` Thu Nguyen @ 2021-01-06 21:57 ` Bills, Jason M 2021-01-10 23:57 ` Andrew Jeffery 1 sibling, 0 replies; 7+ messages in thread From: Bills, Jason M @ 2021-01-06 21:57 UTC (permalink / raw) To: openbmc 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. > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GPIO pin is reset to default value after release. 2021-01-06 2:14 ` Thu Nguyen 2021-01-06 21:57 ` Bills, Jason M @ 2021-01-10 23:57 ` Andrew Jeffery 1 sibling, 0 replies; 7+ messages in thread From: Andrew Jeffery @ 2021-01-10 23:57 UTC (permalink / raw) To: Thu Nguyen, openbmc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GPIO pin is reset to default value after release. 2021-01-06 1:12 ` Andrew Jeffery 2021-01-06 2:14 ` Thu Nguyen @ 2021-01-07 17:03 ` Patrick Williams 1 sibling, 0 replies; 7+ messages in thread From: Patrick Williams @ 2021-01-07 17:03 UTC (permalink / raw) To: Andrew Jeffery; +Cc: openbmc [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-01-10 23:59 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-05 16:27 GPIO pin is reset to default value after release Thu Nguyen 2021-01-05 17:21 ` Vijay Khemka 2021-01-06 1:12 ` Andrew Jeffery 2021-01-06 2:14 ` Thu Nguyen 2021-01-06 21:57 ` Bills, Jason M 2021-01-10 23:57 ` Andrew Jeffery 2021-01-07 17:03 ` Patrick Williams
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.