* [libgpiod] bug: pull-up does not work @ 2022-03-25 10:02 Jiří Prchal 2022-03-25 14:57 ` Kent Gibson 0 siblings, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2022-03-25 10:02 UTC (permalink / raw) To: linux-gpio Hi, since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result. ~# uname -r 5.17.0-rc7_cpm9g25 floating pins should go with pull-up/down ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 0 0 0 0 0 0 0 0 ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 1 1 0 0 0 0 0 0 ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 0 1 0 1 0 0 0 0 ~# gpioget -v gpioget (libgpiod) v2.0-devel Whats wrong with it? Thanks Jiri ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] bug: pull-up does not work 2022-03-25 10:02 [libgpiod] bug: pull-up does not work Jiří Prchal @ 2022-03-25 14:57 ` Kent Gibson 2022-03-25 15:13 ` Jiří Prchal 0 siblings, 1 reply; 23+ messages in thread From: Kent Gibson @ 2022-03-25 14:57 UTC (permalink / raw) To: Jiří Prchal; +Cc: linux-gpio, brgl On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote: > Hi, > since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch > next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result. > You mean it doesn't work for you on your platform. The libgpiod-2.0 branch is a work in progress and should not be considered the place to go to find solutions to problems with v1.6. Not that I'm saying that the v2 branch doesn't work, I'm actually pretty sure it does, but its purpose is to switch to the latest kernel uAPI, not to provide fixes, should they be needed, for v1.6. > ~# uname -r > 5.17.0-rc7_cpm9g25 > > floating pins should go with pull-up/down > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > 0 0 0 0 0 0 0 0 > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > 1 1 0 0 0 0 0 0 > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > 0 1 0 1 0 0 0 0 > > ~# gpioget -v > gpioget (libgpiod) v2.0-devel > > Whats wrong with it? You forgot to mention which of those pins are floating. Or what gpiochip3 is and whether it supports biasing. So does your chip support pull-up/down? The kernel can only enable it if the hardware and pinctrl driver supports it. If the hardware doesn't support it then attempting to set the pull-up/down is quietly ignored, which would be consistent with what you are seeing. Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] bug: pull-up does not work 2022-03-25 14:57 ` Kent Gibson @ 2022-03-25 15:13 ` Jiří Prchal 2022-03-25 16:01 ` Kent Gibson 0 siblings, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2022-03-25 15:13 UTC (permalink / raw) To: Kent Gibson; +Cc: linux-gpio, brgl On 25. 03. 22 15:57, Kent Gibson wrote: > On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote: >> Hi, >> since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch >> next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result. >> > > You mean it doesn't work for you on your platform. > > The libgpiod-2.0 branch is a work in progress and should not be considered > the place to go to find solutions to problems with v1.6. > Not that I'm saying that the v2 branch doesn't work, I'm actually pretty > sure it does, but its purpose is to switch to the latest kernel uAPI, not > to provide fixes, should they be needed, for v1.6. Just thought api v1 doesn't support pull-ups so tried v2. > >> ~# uname -r >> 5.17.0-rc7_cpm9g25 >> >> floating pins should go with pull-up/down >> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >> 0 0 0 0 0 0 0 0 >> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >> 1 1 0 0 0 0 0 0 >> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >> 0 1 0 1 0 0 0 0 >> >> ~# gpioget -v >> gpioget (libgpiod) v2.0-devel >> >> Whats wrong with it? > > You forgot to mention which of those pins are floating. All of them. > Or what gpiochip3 is and whether it supports biasing. AT91SAM9G25, hw supports pull-ups. > > So does your chip support pull-up/down? > The kernel can only enable it if the hardware and pinctrl driver supports it. Is there possibility that pinctrl doesn't support it? I think other gpios used in kernel are with pull-up. Example: pinctrl@fffff400 { 1wire { pinctrl_1wire: 1wire-0 { atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0 PIO, pull-up */ }; }; }; > If the hardware doesn't support it then attempting to set the > pull-up/down is quietly ignored, which would be consistent with what you > are seeing. > > Cheers, > Kent. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] bug: pull-up does not work 2022-03-25 15:13 ` Jiří Prchal @ 2022-03-25 16:01 ` Kent Gibson 2022-03-28 7:12 ` Jiří Prchal 0 siblings, 1 reply; 23+ messages in thread From: Kent Gibson @ 2022-03-25 16:01 UTC (permalink / raw) To: Jiří Prchal; +Cc: linux-gpio, brgl, andy.shevchenko On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote: > > > On 25. 03. 22 15:57, Kent Gibson wrote: > > On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote: > > > Hi, > > > since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch > > > next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result. > > > > > > > You mean it doesn't work for you on your platform. > > > > The libgpiod-2.0 branch is a work in progress and should not be considered > > the place to go to find solutions to problems with v1.6. > > Not that I'm saying that the v2 branch doesn't work, I'm actually pretty > > sure it does, but its purpose is to switch to the latest kernel uAPI, not > > to provide fixes, should they be needed, for v1.6. > Just thought api v1 doesn't support pull-ups so tried v2. v1 does support bias since Linux v5.5, and libgpiod added support in v1.5. > > > > > ~# uname -r > > > 5.17.0-rc7_cpm9g25 > > > > > > floating pins should go with pull-up/down > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > 0 0 0 0 0 0 0 0 > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > 1 1 0 0 0 0 0 0 > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > 0 1 0 1 0 0 0 0 > > > > > > ~# gpioget -v > > > gpioget (libgpiod) v2.0-devel > > > > > > Whats wrong with it? > > > > You forgot to mention which of those pins are floating. > All of them. > > Or what gpiochip3 is and whether it supports biasing. > AT91SAM9G25, hw supports pull-ups. > > > > So does your chip support pull-up/down? > > The kernel can only enable it if the hardware and pinctrl driver supports it. > Is there possibility that pinctrl doesn't support it? I think other gpios > used in kernel are with pull-up. > Example: > pinctrl@fffff400 { > 1wire { > pinctrl_1wire: 1wire-0 { > atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0 > PIO, pull-up */ > }; > }; > }; > Pinctrl and device tree are outside my area, but my understanding is that setting via DT is a separate interface, so while it may be supported by DT it may not be via the gpiolib interface. But I will defer to anyone else on that. (CCing in Andy since I'm pretty sure he would know) Not sure which pinctrl is relevant for your case. pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib interface, but pinctrl-at91-pio4 does, so my guess would be you are using the pinctrl-at91. But again, this is outside my area so you would need to confirm that yourself or get feedback from someone else. If you determine that you are using a pinctrl that supports setting bias via gpiolib then we'll have to do some more digging. Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] bug: pull-up does not work 2022-03-25 16:01 ` Kent Gibson @ 2022-03-28 7:12 ` Jiří Prchal 2022-03-28 8:08 ` Kent Gibson 0 siblings, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2022-03-28 7:12 UTC (permalink / raw) To: Kent Gibson; +Cc: linux-gpio, brgl, andy.shevchenko On 25. 03. 22 17:01, Kent Gibson wrote: > On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote: >> >> >> On 25. 03. 22 15:57, Kent Gibson wrote: >>> On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote: >>>> Hi, >>>> since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch >>>> next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result. >>>> >>> >>> You mean it doesn't work for you on your platform. >>> >>> The libgpiod-2.0 branch is a work in progress and should not be considered >>> the place to go to find solutions to problems with v1.6. >>> Not that I'm saying that the v2 branch doesn't work, I'm actually pretty >>> sure it does, but its purpose is to switch to the latest kernel uAPI, not >>> to provide fixes, should they be needed, for v1.6. >> Just thought api v1 doesn't support pull-ups so tried v2. > > v1 does support bias since Linux v5.5, and libgpiod added support in v1.5. > >>> >>>> ~# uname -r >>>> 5.17.0-rc7_cpm9g25 >>>> >>>> floating pins should go with pull-up/down >>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >>>> 0 0 0 0 0 0 0 0 >>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >>>> 1 1 0 0 0 0 0 0 >>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >>>> 0 1 0 1 0 0 0 0 >>>> >>>> ~# gpioget -v >>>> gpioget (libgpiod) v2.0-devel >>>> >>>> Whats wrong with it? >>> >>> You forgot to mention which of those pins are floating. >> All of them. >>> Or what gpiochip3 is and whether it supports biasing. >> AT91SAM9G25, hw supports pull-ups. >>> >>> So does your chip support pull-up/down? >>> The kernel can only enable it if the hardware and pinctrl driver supports it. >> Is there possibility that pinctrl doesn't support it? I think other gpios >> used in kernel are with pull-up. >> Example: >> pinctrl@fffff400 { >> 1wire { >> pinctrl_1wire: 1wire-0 { >> atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0 >> PIO, pull-up */ >> }; >> }; >> }; >> > > Pinctrl and device tree are outside my area, but my understanding is > that setting via DT is a separate interface, so while it may be > supported by DT it may not be via the gpiolib interface. > But I will defer to anyone else on that. > (CCing in Andy since I'm pretty sure he would know) > > Not sure which pinctrl is relevant for your case. > pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib > interface, but pinctrl-at91-pio4 does, so my guess would be you are using > the pinctrl-at91. pinctrl-at91-pio4 didn't help, syminfo says "for Atmel PIO4 controller available on sama5d2 SoC" but my is sam9g25. How can I find out if it supports gpiolib? > > But again, this is outside my area so you would need to confirm that > yourself or get feedback from someone else. > If you determine that you are using a pinctrl that supports setting > bias via gpiolib then we'll have to do some more digging. > > Cheers, > Kent. > Thanks Jiri ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] bug: pull-up does not work 2022-03-28 7:12 ` Jiří Prchal @ 2022-03-28 8:08 ` Kent Gibson 2022-03-28 8:58 ` Jiří Prchal 2022-06-28 13:08 ` [libgpiod] feature request: output state read and sustain Jiří Prchal 0 siblings, 2 replies; 23+ messages in thread From: Kent Gibson @ 2022-03-28 8:08 UTC (permalink / raw) To: Jiří Prchal; +Cc: linux-gpio, brgl, andy.shevchenko On Mon, Mar 28, 2022 at 09:12:16AM +0200, Jiří Prchal wrote: > > > On 25. 03. 22 17:01, Kent Gibson wrote: > > On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote: > > > > > > > > > On 25. 03. 22 15:57, Kent Gibson wrote: > > > > On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote: > > > > > Hi, > > > > > since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch > > > > > next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result. > > > > > > > > > > > > > You mean it doesn't work for you on your platform. > > > > > > > > The libgpiod-2.0 branch is a work in progress and should not be considered > > > > the place to go to find solutions to problems with v1.6. > > > > Not that I'm saying that the v2 branch doesn't work, I'm actually pretty > > > > sure it does, but its purpose is to switch to the latest kernel uAPI, not > > > > to provide fixes, should they be needed, for v1.6. > > > Just thought api v1 doesn't support pull-ups so tried v2. > > > > v1 does support bias since Linux v5.5, and libgpiod added support in v1.5. > > > > > > > > > > > ~# uname -r > > > > > 5.17.0-rc7_cpm9g25 > > > > > > > > > > floating pins should go with pull-up/down > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > > > 0 0 0 0 0 0 0 0 > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > > > 1 1 0 0 0 0 0 0 > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > > > 0 1 0 1 0 0 0 0 > > > > > > > > > > ~# gpioget -v > > > > > gpioget (libgpiod) v2.0-devel > > > > > > > > > > Whats wrong with it? > > > > > > > > You forgot to mention which of those pins are floating. > > > All of them. > > > > Or what gpiochip3 is and whether it supports biasing. > > > AT91SAM9G25, hw supports pull-ups. > > > > > > > > So does your chip support pull-up/down? > > > > The kernel can only enable it if the hardware and pinctrl driver supports it. > > > Is there possibility that pinctrl doesn't support it? I think other gpios > > > used in kernel are with pull-up. > > > Example: > > > pinctrl@fffff400 { > > > 1wire { > > > pinctrl_1wire: 1wire-0 { > > > atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0 > > > PIO, pull-up */ > > > }; > > > }; > > > }; > > > > > > > Pinctrl and device tree are outside my area, but my understanding is > > that setting via DT is a separate interface, so while it may be > > supported by DT it may not be via the gpiolib interface. > > But I will defer to anyone else on that. > > (CCing in Andy since I'm pretty sure he would know) > > > > Not sure which pinctrl is relevant for your case. > > pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib > > interface, but pinctrl-at91-pio4 does, so my guess would be you are using > > the pinctrl-at91. > pinctrl-at91-pio4 didn't help, syminfo says "for Atmel PIO4 controller > available on sama5d2 SoC" but my is sam9g25. > How can I find out if it supports gpiolib? > > What does gpiodetect report? That should given an indication which driver is being used. Cheers, Kent. > > But again, this is outside my area so you would need to confirm that > > yourself or get feedback from someone else. > > If you determine that you are using a pinctrl that supports setting > > bias via gpiolib then we'll have to do some more digging. > > > > Cheers, > > Kent. > > > Thanks > Jiri ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] bug: pull-up does not work 2022-03-28 8:08 ` Kent Gibson @ 2022-03-28 8:58 ` Jiří Prchal 2022-03-28 9:56 ` Kent Gibson 2022-06-28 13:08 ` [libgpiod] feature request: output state read and sustain Jiří Prchal 1 sibling, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2022-03-28 8:58 UTC (permalink / raw) To: Kent Gibson; +Cc: linux-gpio, brgl, andy.shevchenko On 28. 03. 22 10:08, Kent Gibson wrote: > On Mon, Mar 28, 2022 at 09:12:16AM +0200, Jiří Prchal wrote: >> >> >> On 25. 03. 22 17:01, Kent Gibson wrote: >>> On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote: >>>> >>>> >>>> On 25. 03. 22 15:57, Kent Gibson wrote: >>>>> On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote: >>>>>> Hi, >>>>>> since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch >>>>>> next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result. >>>>>> >>>>> >>>>> You mean it doesn't work for you on your platform. >>>>> >>>>> The libgpiod-2.0 branch is a work in progress and should not be considered >>>>> the place to go to find solutions to problems with v1.6. >>>>> Not that I'm saying that the v2 branch doesn't work, I'm actually pretty >>>>> sure it does, but its purpose is to switch to the latest kernel uAPI, not >>>>> to provide fixes, should they be needed, for v1.6. >>>> Just thought api v1 doesn't support pull-ups so tried v2. >>> >>> v1 does support bias since Linux v5.5, and libgpiod added support in v1.5. >>> >>>>> >>>>>> ~# uname -r >>>>>> 5.17.0-rc7_cpm9g25 >>>>>> >>>>>> floating pins should go with pull-up/down >>>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >>>>>> 1 1 0 0 0 0 0 0 >>>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 >>>>>> 0 1 0 1 0 0 0 0 >>>>>> >>>>>> ~# gpioget -v >>>>>> gpioget (libgpiod) v2.0-devel >>>>>> >>>>>> Whats wrong with it? >>>>> >>>>> You forgot to mention which of those pins are floating. >>>> All of them. >>>>> Or what gpiochip3 is and whether it supports biasing. >>>> AT91SAM9G25, hw supports pull-ups. >>>>> >>>>> So does your chip support pull-up/down? >>>>> The kernel can only enable it if the hardware and pinctrl driver supports it. >>>> Is there possibility that pinctrl doesn't support it? I think other gpios >>>> used in kernel are with pull-up. >>>> Example: >>>> pinctrl@fffff400 { >>>> 1wire { >>>> pinctrl_1wire: 1wire-0 { >>>> atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0 >>>> PIO, pull-up */ >>>> }; >>>> }; >>>> }; >>>> >>> >>> Pinctrl and device tree are outside my area, but my understanding is >>> that setting via DT is a separate interface, so while it may be >>> supported by DT it may not be via the gpiolib interface. >>> But I will defer to anyone else on that. >>> (CCing in Andy since I'm pretty sure he would know) >>> >>> Not sure which pinctrl is relevant for your case. >>> pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib >>> interface, but pinctrl-at91-pio4 does, so my guess would be you are using >>> the pinctrl-at91. >> pinctrl-at91-pio4 didn't help, syminfo says "for Atmel PIO4 controller >> available on sama5d2 SoC" but my is sam9g25. >> How can I find out if it supports gpiolib? >>> > > What does gpiodetect report? > That should given an indication which driver is being used. # gpiodetect gpiochip0 [fffff400.gpio] (32 lines) gpiochip1 [fffff600.gpio] (19 lines) gpiochip2 [fffff800.gpio] (32 lines) gpiochip3 [fffffa00.gpio] (22 lines) Compiled and linked both pinctrl. > > Cheers, > Kent. > >>> But again, this is outside my area so you would need to confirm that >>> yourself or get feedback from someone else. >>> If you determine that you are using a pinctrl that supports setting >>> bias via gpiolib then we'll have to do some more digging. >>> >>> Cheers, >>> Kent. >>> >> Thanks >> Jiri ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] bug: pull-up does not work 2022-03-28 8:58 ` Jiří Prchal @ 2022-03-28 9:56 ` Kent Gibson 0 siblings, 0 replies; 23+ messages in thread From: Kent Gibson @ 2022-03-28 9:56 UTC (permalink / raw) To: Jiří Prchal; +Cc: linux-gpio, brgl, andy.shevchenko On Mon, Mar 28, 2022 at 10:58:20AM +0200, Jiří Prchal wrote: > > > On 28. 03. 22 10:08, Kent Gibson wrote: > > On Mon, Mar 28, 2022 at 09:12:16AM +0200, Jiří Prchal wrote: > > > > > > > > > On 25. 03. 22 17:01, Kent Gibson wrote: > > > > On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote: > > > > > > > > > > > > > > > On 25. 03. 22 15:57, Kent Gibson wrote: > > > > > > On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote: > > > > > > > Hi, > > > > > > > since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch > > > > > > > next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result. > > > > > > > > > > > > > > > > > > > You mean it doesn't work for you on your platform. > > > > > > > > > > > > The libgpiod-2.0 branch is a work in progress and should not be considered > > > > > > the place to go to find solutions to problems with v1.6. > > > > > > Not that I'm saying that the v2 branch doesn't work, I'm actually pretty > > > > > > sure it does, but its purpose is to switch to the latest kernel uAPI, not > > > > > > to provide fixes, should they be needed, for v1.6. > > > > > Just thought api v1 doesn't support pull-ups so tried v2. > > > > > > > > v1 does support bias since Linux v5.5, and libgpiod added support in v1.5. > > > > > > > > > > > > > > > > > ~# uname -r > > > > > > > 5.17.0-rc7_cpm9g25 > > > > > > > > > > > > > > floating pins should go with pull-up/down > > > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > > > > > 0 0 0 0 0 0 0 0 > > > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > > > > > 1 1 0 0 0 0 0 0 > > > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20 > > > > > > > 0 1 0 1 0 0 0 0 > > > > > > > > > > > > > > ~# gpioget -v > > > > > > > gpioget (libgpiod) v2.0-devel > > > > > > > > > > > > > > Whats wrong with it? > > > > > > > > > > > > You forgot to mention which of those pins are floating. > > > > > All of them. > > > > > > Or what gpiochip3 is and whether it supports biasing. > > > > > AT91SAM9G25, hw supports pull-ups. > > > > > > > > > > > > So does your chip support pull-up/down? > > > > > > The kernel can only enable it if the hardware and pinctrl driver supports it. > > > > > Is there possibility that pinctrl doesn't support it? I think other gpios > > > > > used in kernel are with pull-up. > > > > > Example: > > > > > pinctrl@fffff400 { > > > > > 1wire { > > > > > pinctrl_1wire: 1wire-0 { > > > > > atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0 > > > > > PIO, pull-up */ > > > > > }; > > > > > }; > > > > > }; > > > > > > > > > > > > > Pinctrl and device tree are outside my area, but my understanding is > > > > that setting via DT is a separate interface, so while it may be > > > > supported by DT it may not be via the gpiolib interface. > > > > But I will defer to anyone else on that. > > > > (CCing in Andy since I'm pretty sure he would know) > > > > > > > > Not sure which pinctrl is relevant for your case. > > > > pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib > > > > interface, but pinctrl-at91-pio4 does, so my guess would be you are using > > > > the pinctrl-at91. > > > pinctrl-at91-pio4 didn't help, syminfo says "for Atmel PIO4 controller > > > available on sama5d2 SoC" but my is sam9g25. > > > How can I find out if it supports gpiolib? > > > > > > > > What does gpiodetect report? > > That should given an indication which driver is being used. > # gpiodetect > gpiochip0 [fffff400.gpio] (32 lines) > gpiochip1 [fffff600.gpio] (19 lines) > gpiochip2 [fffff800.gpio] (32 lines) > gpiochip3 [fffffa00.gpio] (22 lines) > > Compiled and linked both pinctrl. Ok, that isn't helpful, for me anyway, and I'm not sure where to go from there. Hopefully someone else can chip in. Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* [libgpiod] feature request: output state read and sustain 2022-03-28 8:08 ` Kent Gibson 2022-03-28 8:58 ` Jiří Prchal @ 2022-06-28 13:08 ` Jiří Prchal 2022-06-29 7:23 ` Kent Gibson 1 sibling, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2022-06-28 13:08 UTC (permalink / raw) To: linux-gpio; +Cc: bartekgola Hi, using new libgpiod / chardev driver, is there any way to get state of output? I mean one process sets it for example to 1 and another process reads this output state for example to show that on web page. I have to say that old sysfs interface was more user friendly... And at second: it would be better to NOT "the state of a GPIO line controlled over the character device reverts to default when the last process referencing the file descriptor representing the device file exits." "Set and forget" behavior is more natural to what some gpios are used. For example resetting external modems, need set 1 for short time, then to 0 and leave it for long long time until next reset is needed. It's non sense to keep running some process only to keep output at 0. Thanks Jiri ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-28 13:08 ` [libgpiod] feature request: output state read and sustain Jiří Prchal @ 2022-06-29 7:23 ` Kent Gibson 2022-06-29 9:25 ` Jiří Prchal 0 siblings, 1 reply; 23+ messages in thread From: Kent Gibson @ 2022-06-29 7:23 UTC (permalink / raw) To: Jiří Prchal; +Cc: linux-gpio, brgl On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: > Hi, > using new libgpiod / chardev driver, is there any way to get state of > output? I mean one process sets it for example to 1 and another process > reads this output state for example to show that on web page. > I have to say that old sysfs interface was more user friendly... > "new" being anything since Linux 4.8 ;-)? And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem provide an interface to the chip driver. More on that later. Only the process holding the line has access to the current value. If you need that value elsewhere then it has to be published by that process - it is not available through the GPIO API itself. There is nothing preventing that process publishing the value in whatever way is appropriate to your application. e.g. write it to a file that can be read by your webapp, just as it would from sysfs. Less restrictive access models are frequently "more user friendly", but have other issues. e.g. some misbehaving process just reset your modem for you. And sysfs has other great features like being slow and being complete rubbish for events on input lines. > And at second: it would be better to NOT "the state of a GPIO line > controlled over the character device reverts to default when the last > process referencing the file descriptor representing the device file exits." > "Set and forget" behavior is more natural to what some gpios are used. For > example resetting external modems, need set 1 for short time, then to 0 and > leave it for long long time until next reset is needed. It's non sense to > keep running some process only to keep output at 0. Agreed, that might be more natural, but that behaviour is not by choice, it is a consequence of the kernel internals. In short, if the GPIO subsystem does not hold the chip then the driver is free to do what it likes to it. So when you release a line all bets are off. It may stay where you left it, but it may not - it may even switch to an input - it depends on the driver. If it works for you that's great, but without major kernel changes libgpiod has no better option than to provide the caveat as the "set and forget" behaviour is something that it cannot guarantee. Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 7:23 ` Kent Gibson @ 2022-06-29 9:25 ` Jiří Prchal 2022-06-29 10:10 ` Kent Gibson 2022-06-29 10:27 ` Andy Shevchenko 0 siblings, 2 replies; 23+ messages in thread From: Jiří Prchal @ 2022-06-29 9:25 UTC (permalink / raw) To: Kent Gibson; +Cc: linux-gpio, brgl On 29. 06. 22 9:23, Kent Gibson wrote: > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: >> Hi, >> using new libgpiod / chardev driver, is there any way to get state of >> output? I mean one process sets it for example to 1 and another process >> reads this output state for example to show that on web page. >> I have to say that old sysfs interface was more user friendly... >> > > "new" being anything since Linux 4.8 ;-)? > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem > provide an interface to the chip driver. More on that later. > > Only the process holding the line has access to the current value. > If you need that value elsewhere then it has to be published by that > process - it is not available through the GPIO API itself. > There is nothing preventing that process publishing the value > in whatever way is appropriate to your application. > e.g. write it to a file that can be read by your webapp, just as it > would from sysfs. > > Less restrictive access models are frequently "more user friendly", but > have other issues. e.g. some misbehaving process just reset your > modem for you. > > And sysfs has other great features like being slow and being complete > rubbish for events on input lines. > >> And at second: it would be better to NOT "the state of a GPIO line >> controlled over the character device reverts to default when the last >> process referencing the file descriptor representing the device file exits." >> "Set and forget" behavior is more natural to what some gpios are used. For >> example resetting external modems, need set 1 for short time, then to 0 and >> leave it for long long time until next reset is needed. It's non sense to >> keep running some process only to keep output at 0. > > Agreed, that might be more natural, but that behaviour is not by choice, > it is a consequence of the kernel internals. In short, if the GPIO > subsystem does not hold the chip then the driver is free to do what it > likes to it. > So when you release a line all bets are off. > It may stay where you left it, but it may not - it may even switch to an > input - it depends on the driver. Does it mean that without changing this particular line it could be changed? For example by setting another line in chip? > If it works for you that's great, but without major kernel changes > libgpiod has no better option than to provide the caveat as the "set and > forget" behaviour is something that it cannot guarantee. Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario: start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things when the proces dies systemd will start it again and another scenario: proces checks time, if is the right time -> gpioset =1 other proces reads output and print out on web Jiri > > Cheers, > Kent. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 9:25 ` Jiří Prchal @ 2022-06-29 10:10 ` Kent Gibson 2022-06-29 10:27 ` Andy Shevchenko 1 sibling, 0 replies; 23+ messages in thread From: Kent Gibson @ 2022-06-29 10:10 UTC (permalink / raw) To: Jiří Prchal; +Cc: linux-gpio, brgl On Wed, Jun 29, 2022 at 11:25:57AM +0200, Jiří Prchal wrote: > > > On 29. 06. 22 9:23, Kent Gibson wrote: > > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: > > > Hi, > > > using new libgpiod / chardev driver, is there any way to get state of > > > output? I mean one process sets it for example to 1 and another process > > > reads this output state for example to show that on web page. > > > I have to say that old sysfs interface was more user friendly... > > > > > > > "new" being anything since Linux 4.8 ;-)? > > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem > > provide an interface to the chip driver. More on that later. > > > > Only the process holding the line has access to the current value. > > If you need that value elsewhere then it has to be published by that > > process - it is not available through the GPIO API itself. > > There is nothing preventing that process publishing the value > > in whatever way is appropriate to your application. > > e.g. write it to a file that can be read by your webapp, just as it > > would from sysfs. > > > > Less restrictive access models are frequently "more user friendly", but > > have other issues. e.g. some misbehaving process just reset your > > modem for you. > > > > And sysfs has other great features like being slow and being complete > > rubbish for events on input lines. > > > > > And at second: it would be better to NOT "the state of a GPIO line > > > controlled over the character device reverts to default when the last > > > process referencing the file descriptor representing the device file exits." > > > "Set and forget" behavior is more natural to what some gpios are used. For > > > example resetting external modems, need set 1 for short time, then to 0 and > > > leave it for long long time until next reset is needed. It's non sense to > > > keep running some process only to keep output at 0. > > > > Agreed, that might be more natural, but that behaviour is not by choice, > > it is a consequence of the kernel internals. In short, if the GPIO > > subsystem does not hold the chip then the driver is free to do what it > > likes to it. > > So when you release a line all bets are off. > > It may stay where you left it, but it may not - it may even switch to an > > input - it depends on the driver. > Does it mean that without changing this particular line it could be changed? For example by setting another line in chip? > If you hold a line then it is guaranteed to remain in the state you request. Changing or releasing other lines will not alter that line. If you release a line then other processes are free to request it and alter it. But if no other process request it, it will generally will remain in the state you left it. Generally. The exception is if you release the last requested line on the chip, in which case the GPIO subsystem will release the chip to the driver and what happens to all the lines on the chip after that is up to the driver. The big problem is you never know if the line you are releasing is the last requested line. Unless you explicitly hold at least one line. > > If it works for you that's great, but without major kernel changes > > libgpiod has no better option than to provide the caveat as the "set and > > forget" behaviour is something that it cannot guarantee. > Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario: > start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things > when the proces dies systemd will start it again > No, you don't have to emulate sysfs, you can do whatever works for you, that was just an example. The libgpiod tools are not the only interface libgpiod provides - they are just the command line/shell interface. You would not call gpioset repeatedly, you would request the line using libgpiod (for C), or the appropriate bindings for the language you are working in, and then set the line as required in your program. If you are working in shell with libgpiod v1.6.3 then there is no way to hold a line and subsequently change it. You would have to repeatedly call gpioset and hope for the best in between times. For libgpiod v2 I'm working on an interactive mode for gpioset that keeps it running and holding the line(s) and you pipe set commands to it from your script as required. If you need anything more complicated for scripting then the Python bindings would be the way to go. > and another scenario: > proces checks time, if is the right time -> gpioset =1 > other proces reads output and print out on web > line manager process: request line (using appropriate binding) wait until whenever set=1 (using appropriate binding) publish line state where web server can see ... web server process: webserver asked for state returns last published value Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 9:25 ` Jiří Prchal 2022-06-29 10:10 ` Kent Gibson @ 2022-06-29 10:27 ` Andy Shevchenko 2022-06-29 10:47 ` Kent Gibson 1 sibling, 1 reply; 23+ messages in thread From: Andy Shevchenko @ 2022-06-29 10:27 UTC (permalink / raw) To: Jiří Prchal Cc: Kent Gibson, open list:GPIO SUBSYSTEM, Bartosz Golaszewski On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: > On 29. 06. 22 9:23, Kent Gibson wrote: > > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: > >> using new libgpiod / chardev driver, is there any way to get state of > >> output? I mean one process sets it for example to 1 and another process > >> reads this output state for example to show that on web page. I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO chips may not allow this on H/W level and when reading they always will get the value of Input Buffer (now imagine if the line is configured as Output with Input being disconnected from the physical pin). > >> I have to say that old sysfs interface was more user friendly... And much more buggy and PITA. > > "new" being anything since Linux 4.8 ;-)? > > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem > > provide an interface to the chip driver. More on that later. > > > > Only the process holding the line has access to the current value. > > If you need that value elsewhere then it has to be published by that > > process - it is not available through the GPIO API itself. > > There is nothing preventing that process publishing the value > > in whatever way is appropriate to your application. > > e.g. write it to a file that can be read by your webapp, just as it > > would from sysfs. > > > > Less restrictive access models are frequently "more user friendly", but > > have other issues. e.g. some misbehaving process just reset your > > modem for you. > > > > And sysfs has other great features like being slow and being complete > > rubbish for events on input lines. > > > >> And at second: it would be better to NOT "the state of a GPIO line > >> controlled over the character device reverts to default when the last > >> process referencing the file descriptor representing the device file exits." > >> "Set and forget" behavior is more natural to what some gpios are used. For > >> example resetting external modems, need set 1 for short time, then to 0 and > >> leave it for long long time until next reset is needed. It's non sense to > >> keep running some process only to keep output at 0. > > > > Agreed, that might be more natural, but that behaviour is not by choice, > > it is a consequence of the kernel internals. In short, if the GPIO > > subsystem does not hold the chip then the driver is free to do what it > > likes to it. > > So when you release a line all bets are off. > > It may stay where you left it, but it may not - it may even switch to an > > input - it depends on the driver. > Does it mean that without changing this particular line it could be changed? For example by setting another line in chip? No, it's only about the line in question. > > If it works for you that's great, but without major kernel changes > > libgpiod has no better option than to provide the caveat as the "set and > > forget" behaviour is something that it cannot guarantee. > Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario: > start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things > when the proces dies systemd will start it again Do not use shell. Use proper programming language that may give you an easier way of handling this, i.e. _context_. Shell tools are _context-less_ and here is the problem you are trying to solve, but from the wrong end. > and another scenario: > proces checks time, if is the right time -> gpioset =1 > other proces reads output and print out on web -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 10:27 ` Andy Shevchenko @ 2022-06-29 10:47 ` Kent Gibson 2022-06-29 10:58 ` Andy Shevchenko 2022-06-29 11:17 ` Jiří Prchal 0 siblings, 2 replies; 23+ messages in thread From: Kent Gibson @ 2022-06-29 10:47 UTC (permalink / raw) To: Andy Shevchenko Cc: Jiří Prchal, open list:GPIO SUBSYSTEM, Bartosz Golaszewski On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: > > On 29. 06. 22 9:23, Kent Gibson wrote: > > > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: > > > >> using new libgpiod / chardev driver, is there any way to get state of > > >> output? I mean one process sets it for example to 1 and another process > > >> reads this output state for example to show that on web page. > > I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO > chips may not allow this on H/W level and when reading they always > will get the value of Input Buffer (now imagine if the line is > configured as Output with Input being disconnected from the physical > pin). > Agreed. Userspace should know the value they set the output to, and so have no need to read it back. GPIO is not NVM. The only time it makes sense to me to go to the hardware for output values is for open-drain outputs, but as you say, even then it would depend in the hardware and driver supporting it. And for those cases it might be better to explicitly emulate open-drain and switch the line to an input when not being actively drive. > > >> I have to say that old sysfs interface was more user friendly... > > And much more buggy and PITA. > > > > "new" being anything since Linux 4.8 ;-)? > > > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem > > > provide an interface to the chip driver. More on that later. > > > > > > Only the process holding the line has access to the current value. > > > If you need that value elsewhere then it has to be published by that > > > process - it is not available through the GPIO API itself. > > > There is nothing preventing that process publishing the value > > > in whatever way is appropriate to your application. > > > e.g. write it to a file that can be read by your webapp, just as it > > > would from sysfs. > > > > > > Less restrictive access models are frequently "more user friendly", but > > > have other issues. e.g. some misbehaving process just reset your > > > modem for you. > > > > > > And sysfs has other great features like being slow and being complete > > > rubbish for events on input lines. > > > > > >> And at second: it would be better to NOT "the state of a GPIO line > > >> controlled over the character device reverts to default when the last > > >> process referencing the file descriptor representing the device file exits." > > >> "Set and forget" behavior is more natural to what some gpios are used. For > > >> example resetting external modems, need set 1 for short time, then to 0 and > > >> leave it for long long time until next reset is needed. It's non sense to > > >> keep running some process only to keep output at 0. > > > > > > Agreed, that might be more natural, but that behaviour is not by choice, > > > it is a consequence of the kernel internals. In short, if the GPIO > > > subsystem does not hold the chip then the driver is free to do what it > > > likes to it. > > > So when you release a line all bets are off. > > > It may stay where you left it, but it may not - it may even switch to an > > > input - it depends on the driver. > > Does it mean that without changing this particular line it could be changed? For example by setting another line in chip? > > No, it's only about the line in question. > > > > If it works for you that's great, but without major kernel changes > > > libgpiod has no better option than to provide the caveat as the "set and > > > forget" behaviour is something that it cannot guarantee. > > Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario: > > start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things > > when the proces dies systemd will start it again > > Do not use shell. Use proper programming language that may give you an > easier way of handling this, i.e. _context_. Shell tools are > _context-less_ and here is the problem you are trying to solve, but > from the wrong end. > Actually my proposed gpioset for v2 will support running interactively so it can maintain context and be driven from shell - for cases where basic scripting will suffice. Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 10:47 ` Kent Gibson @ 2022-06-29 10:58 ` Andy Shevchenko 2022-06-29 11:20 ` Kent Gibson 2022-06-29 12:56 ` Bartosz Golaszewski 2022-06-29 11:17 ` Jiří Prchal 1 sibling, 2 replies; 23+ messages in thread From: Andy Shevchenko @ 2022-06-29 10:58 UTC (permalink / raw) To: Kent Gibson Cc: Jiří Prchal, open list:GPIO SUBSYSTEM, Bartosz Golaszewski On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote: > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: ... > > Do not use shell. Use proper programming language that may give you an > > easier way of handling this, i.e. _context_. Shell tools are > > _context-less_ and here is the problem you are trying to solve, but > > from the wrong end. > > Actually my proposed gpioset for v2 will support running interactively > so it can maintain context and be driven from shell - for cases where > basic scripting will suffice. Dunno if it's the right direction and if I missed any (additional) discussion. As far as I remember the idea was to introduce DBus aware daemon that should handle the context of the line and at the same time consider security implications. Allowing shell to be context-aware is a hidden mine field. What will happen if the script/user forgets to move the line to the proper state and the chip will drain a lot of current? So, at least PM concerns just popped up immediately to my mind. What else can be problematic? So, I dunno, it's a good idea to allow shell to leave a line in some state when the user actually doesn't care about it anymore. At the bare minimum this mustn't be default behaviour. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 10:58 ` Andy Shevchenko @ 2022-06-29 11:20 ` Kent Gibson 2022-06-29 11:55 ` Andy Shevchenko 2022-06-29 12:56 ` Bartosz Golaszewski 1 sibling, 1 reply; 23+ messages in thread From: Kent Gibson @ 2022-06-29 11:20 UTC (permalink / raw) To: Andy Shevchenko Cc: Jiří Prchal, open list:GPIO SUBSYSTEM, Bartosz Golaszewski On Wed, Jun 29, 2022 at 12:58:18PM +0200, Andy Shevchenko wrote: > On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: > > ... > > > > Do not use shell. Use proper programming language that may give you an > > > easier way of handling this, i.e. _context_. Shell tools are > > > _context-less_ and here is the problem you are trying to solve, but > > > from the wrong end. > > > > Actually my proposed gpioset for v2 will support running interactively > > so it can maintain context and be driven from shell - for cases where > > basic scripting will suffice. > > Dunno if it's the right direction and if I missed any (additional) discussion. > As far as I remember the idea was to introduce DBus aware daemon that > should handle the context of the line and at the same time consider security > implications. Allowing shell to be context-aware is a hidden mine > field. What will happen if the script/user forgets to move the line to > the proper state and the chip will drain a lot of current? So, at > least PM concerns just popped up immediately to my mind. What else can > be problematic? So, I dunno, it's a good idea to allow shell to leave > a line in some state when the user actually doesn't care about it > anymore. At the bare minimum this mustn't be default behaviour. > I don't think it is what you think it is. Take a look. If you don't like it then get Bart to bin it. There was no on-list discussion. I had preliminary disussions with Bart, and had intended to float it as an RFC, but got distracted by other things and ended up going direct to an implementation. Last I heard the DBus daemon is still on the cards, but not sure where Bart is with it, and the gpioset addition is for simpler cases where DBus is overkill or where there is no daemon. It is not the default behaviour, it is an optional mode. gpioset maintains the context, not shell. "User's forgetting" is language independent. Shell scripts matter! What else have I missed replying to? I don't know. And good to see our apparent agreement in the previous mails was just an aberation. I was starting to think there was something wrong with the universe :-|. Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 11:20 ` Kent Gibson @ 2022-06-29 11:55 ` Andy Shevchenko 0 siblings, 0 replies; 23+ messages in thread From: Andy Shevchenko @ 2022-06-29 11:55 UTC (permalink / raw) To: Kent Gibson Cc: Jiří Prchal, open list:GPIO SUBSYSTEM, Bartosz Golaszewski On Wed, Jun 29, 2022 at 1:20 PM Kent Gibson <warthog618@gmail.com> wrote: > On Wed, Jun 29, 2022 at 12:58:18PM +0200, Andy Shevchenko wrote: > > On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote: > > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: ... > > > > Do not use shell. Use proper programming language that may give you an > > > > easier way of handling this, i.e. _context_. Shell tools are > > > > _context-less_ and here is the problem you are trying to solve, but > > > > from the wrong end. > > > > > > Actually my proposed gpioset for v2 will support running interactively > > > so it can maintain context and be driven from shell - for cases where > > > basic scripting will suffice. > > > > Dunno if it's the right direction and if I missed any (additional) discussion. > > As far as I remember the idea was to introduce DBus aware daemon that > > should handle the context of the line and at the same time consider security > > implications. Allowing shell to be context-aware is a hidden mine > > field. What will happen if the script/user forgets to move the line to > > the proper state and the chip will drain a lot of current? So, at > > least PM concerns just popped up immediately to my mind. What else can > > be problematic? So, I dunno, it's a good idea to allow shell to leave > > a line in some state when the user actually doesn't care about it > > anymore. At the bare minimum this mustn't be default behaviour. > > I don't think it is what you think it is. > Take a look. If you don't like it then get Bart to bin it. > > There was no on-list discussion. I had preliminary disussions with Bart, > and had intended to float it as an RFC, but got distracted by other > things and ended up going direct to an implementation. > > Last I heard the DBus daemon is still on the cards, but not sure where > Bart is with it, and the gpioset addition is for simpler cases where > DBus is overkill or where there is no daemon. > > It is not the default behaviour, it is an optional mode. Good! > gpioset maintains the context, not shell. A-ha, that's cool, it pleases me. > "User's forgetting" is language independent. Shell scripts matter! :-) > What else have I missed replying to? I don't know. > > And good to see our apparent agreement in the previous mails was just an > aberation. I was starting to think there was something wrong with the > universe :-|. Ha-ha. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 10:58 ` Andy Shevchenko 2022-06-29 11:20 ` Kent Gibson @ 2022-06-29 12:56 ` Bartosz Golaszewski 2022-06-29 15:22 ` Andy Shevchenko 1 sibling, 1 reply; 23+ messages in thread From: Bartosz Golaszewski @ 2022-06-29 12:56 UTC (permalink / raw) To: Andy Shevchenko Cc: Kent Gibson, Jiří Prchal, open list:GPIO SUBSYSTEM On Wed, Jun 29, 2022 at 12:58 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: > > ... > > > > Do not use shell. Use proper programming language that may give you an > > > easier way of handling this, i.e. _context_. Shell tools are > > > _context-less_ and here is the problem you are trying to solve, but > > > from the wrong end. > > > > Actually my proposed gpioset for v2 will support running interactively > > so it can maintain context and be driven from shell - for cases where > > basic scripting will suffice. > > Dunno if it's the right direction and if I missed any (additional) discussion. > As far as I remember the idea was to introduce DBus aware daemon that > should handle the context of the line and at the same time consider security And it's still very much on the roadmap. > implications. Allowing shell to be context-aware is a hidden mine > field. What will happen if the script/user forgets to move the line to > the proper state and the chip will drain a lot of current? So, at > least PM concerns just popped up immediately to my mind. What else can > be problematic? So, I dunno, it's a good idea to allow shell to leave > a line in some state when the user actually doesn't care about it > anymore. At the bare minimum this mustn't be default behaviour. > It's not much different from letting your current gpioset run in the background, is it? Kent just submitted his first version of gpioset, you can take a look at it and review it. :) Bart > -- > With Best Regards, > Andy Shevchenko ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 12:56 ` Bartosz Golaszewski @ 2022-06-29 15:22 ` Andy Shevchenko 0 siblings, 0 replies; 23+ messages in thread From: Andy Shevchenko @ 2022-06-29 15:22 UTC (permalink / raw) To: Bartosz Golaszewski Cc: Kent Gibson, Jiří Prchal, open list:GPIO SUBSYSTEM On Wed, Jun 29, 2022 at 2:56 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Wed, Jun 29, 2022 at 12:58 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > > > On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote: > > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: > > > > ... > > > > > > Do not use shell. Use proper programming language that may give you an > > > > easier way of handling this, i.e. _context_. Shell tools are > > > > _context-less_ and here is the problem you are trying to solve, but > > > > from the wrong end. > > > > > > Actually my proposed gpioset for v2 will support running interactively > > > so it can maintain context and be driven from shell - for cases where > > > basic scripting will suffice. > > > > Dunno if it's the right direction and if I missed any (additional) discussion. > > As far as I remember the idea was to introduce DBus aware daemon that > > should handle the context of the line and at the same time consider security > > And it's still very much on the roadmap. > > > implications. Allowing shell to be context-aware is a hidden mine > > field. What will happen if the script/user forgets to move the line to > > the proper state and the chip will drain a lot of current? So, at > > least PM concerns just popped up immediately to my mind. What else can > > be problematic? So, I dunno, it's a good idea to allow shell to leave > > a line in some state when the user actually doesn't care about it > > anymore. At the bare minimum this mustn't be default behaviour. > > > > It's not much different from letting your current gpioset run in the > background, is it? > > Kent just submitted his first version of gpioset, you can take a look > at it and review it. :) So far from Kent's and yours explanations there is no evidence to raise an alarm. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 10:47 ` Kent Gibson 2022-06-29 10:58 ` Andy Shevchenko @ 2022-06-29 11:17 ` Jiří Prchal 2022-06-29 11:25 ` Kent Gibson 1 sibling, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2022-06-29 11:17 UTC (permalink / raw) To: Kent Gibson, Andy Shevchenko Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski On 29. 06. 22 12:47, Kent Gibson wrote: > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: >> On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: >>> On 29. 06. 22 9:23, Kent Gibson wrote: >>>> On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: >> >>>>> using new libgpiod / chardev driver, is there any way to get state of >>>>> output? I mean one process sets it for example to 1 and another process >>>>> reads this output state for example to show that on web page. >> >> I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO >> chips may not allow this on H/W level and when reading they always >> will get the value of Input Buffer (now imagine if the line is >> configured as Output with Input being disconnected from the physical >> pin). >> > > Agreed. Userspace should know the value they set the output to, and so > have no need to read it back. GPIO is not NVM. Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0) I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one. > > The only time it makes sense to me to go to the hardware for output > values is for open-drain outputs, but as you say, even then it would > depend in the hardware and driver supporting it. And for those cases it > might be better to explicitly emulate open-drain and switch the line to > an input when not being actively drive. Open-drain outputs as many HW as I know has separate register for output to switch on and off the tranzistor and input register to read value on pin. So 2 values are needed from o-d outputs. OK, first could be write only and second read only. > >>>>> I have to say that old sysfs interface was more user friendly... >> >> And much more buggy and PITA. >> >>>> "new" being anything since Linux 4.8 ;-)? >>>> And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem >>>> provide an interface to the chip driver. More on that later. >>>> >>>> Only the process holding the line has access to the current value. >>>> If you need that value elsewhere then it has to be published by that >>>> process - it is not available through the GPIO API itself. >>>> There is nothing preventing that process publishing the value >>>> in whatever way is appropriate to your application. >>>> e.g. write it to a file that can be read by your webapp, just as it >>>> would from sysfs. >>>> >>>> Less restrictive access models are frequently "more user friendly", but >>>> have other issues. e.g. some misbehaving process just reset your >>>> modem for you. >>>> >>>> And sysfs has other great features like being slow and being complete >>>> rubbish for events on input lines. >>>> >>>>> And at second: it would be better to NOT "the state of a GPIO line >>>>> controlled over the character device reverts to default when the last >>>>> process referencing the file descriptor representing the device file exits." >>>>> "Set and forget" behavior is more natural to what some gpios are used. For >>>>> example resetting external modems, need set 1 for short time, then to 0 and >>>>> leave it for long long time until next reset is needed. It's non sense to >>>>> keep running some process only to keep output at 0. >>>> >>>> Agreed, that might be more natural, but that behaviour is not by choice, >>>> it is a consequence of the kernel internals. In short, if the GPIO >>>> subsystem does not hold the chip then the driver is free to do what it >>>> likes to it. >>>> So when you release a line all bets are off. >>>> It may stay where you left it, but it may not - it may even switch to an >>>> input - it depends on the driver. >>> Does it mean that without changing this particular line it could be changed? For example by setting another line in chip? >> >> No, it's only about the line in question. >> >>>> If it works for you that's great, but without major kernel changes >>>> libgpiod has no better option than to provide the caveat as the "set and >>>> forget" behaviour is something that it cannot guarantee. >>> Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario: >>> start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things >>> when the proces dies systemd will start it again >> >> Do not use shell. Use proper programming language that may give you an >> easier way of handling this, i.e. _context_. Shell tools are >> _context-less_ and here is the problem you are trying to solve, but >> from the wrong end. >> > > Actually my proposed gpioset for v2 will support running interactively > so it can maintain context and be driven from shell - for cases where > basic scripting will suffice. It would be nice. Jiri > > Cheers, > Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 11:17 ` Jiří Prchal @ 2022-06-29 11:25 ` Kent Gibson 2022-06-29 11:48 ` Jiří Prchal 0 siblings, 1 reply; 23+ messages in thread From: Kent Gibson @ 2022-06-29 11:25 UTC (permalink / raw) To: Jiří Prchal Cc: Andy Shevchenko, open list:GPIO SUBSYSTEM, Bartosz Golaszewski On Wed, Jun 29, 2022 at 01:17:54PM +0200, Jiří Prchal wrote: > > > On 29. 06. 22 12:47, Kent Gibson wrote: > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: > > > > On 29. 06. 22 9:23, Kent Gibson wrote: > > > > > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: > > > > > > > > > using new libgpiod / chardev driver, is there any way to get state of > > > > > > output? I mean one process sets it for example to 1 and another process > > > > > > reads this output state for example to show that on web page. > > > > > > I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO > > > chips may not allow this on H/W level and when reading they always > > > will get the value of Input Buffer (now imagine if the line is > > > configured as Output with Input being disconnected from the physical > > > pin). > > > > > > > Agreed. Userspace should know the value they set the output to, and so > > have no need to read it back. GPIO is not NVM. > Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0) > I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one. > No, no it is not RAM. And I have seen hardware where you can't read back the output. And so has Andy apparently. That is the problem - there is lots of hardware out there and we are trying to provide a consistent interface to inconsistent hardware. Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 11:25 ` Kent Gibson @ 2022-06-29 11:48 ` Jiří Prchal 2022-06-29 12:51 ` Kent Gibson 0 siblings, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2022-06-29 11:48 UTC (permalink / raw) To: Kent Gibson Cc: Andy Shevchenko, open list:GPIO SUBSYSTEM, Bartosz Golaszewski On 29. 06. 22 13:25, Kent Gibson wrote: > On Wed, Jun 29, 2022 at 01:17:54PM +0200, Jiří Prchal wrote: >> >> >> On 29. 06. 22 12:47, Kent Gibson wrote: >>> On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: >>>> On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: >>>>> On 29. 06. 22 9:23, Kent Gibson wrote: >>>>>> On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: >>>> >>>>>>> using new libgpiod / chardev driver, is there any way to get state of >>>>>>> output? I mean one process sets it for example to 1 and another process >>>>>>> reads this output state for example to show that on web page. >>>> >>>> I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO >>>> chips may not allow this on H/W level and when reading they always >>>> will get the value of Input Buffer (now imagine if the line is >>>> configured as Output with Input being disconnected from the physical >>>> pin). >>>> >>> >>> Agreed. Userspace should know the value they set the output to, and so >>> have no need to read it back. GPIO is not NVM. >> Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0) >> I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one. >> > > No, no it is not RAM. > > And I have seen hardware where you can't read back the output. > And so has Andy apparently. > That is the problem - there is lots of hardware out there and we are > trying to provide a consistent interface to inconsistent hardware. OK, but if hw supports it why not provide it. And for hw without support keep it's value in memory? Or return to user space with errno indicating "no support"? > > Cheers, > Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [libgpiod] feature request: output state read and sustain 2022-06-29 11:48 ` Jiří Prchal @ 2022-06-29 12:51 ` Kent Gibson 0 siblings, 0 replies; 23+ messages in thread From: Kent Gibson @ 2022-06-29 12:51 UTC (permalink / raw) To: Jiří Prchal Cc: Andy Shevchenko, open list:GPIO SUBSYSTEM, Bartosz Golaszewski On Wed, Jun 29, 2022 at 01:48:17PM +0200, Jiří Prchal wrote: > > > On 29. 06. 22 13:25, Kent Gibson wrote: > > On Wed, Jun 29, 2022 at 01:17:54PM +0200, Jiří Prchal wrote: > > > > > > > > > On 29. 06. 22 12:47, Kent Gibson wrote: > > > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote: > > > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote: > > > > > > On 29. 06. 22 9:23, Kent Gibson wrote: > > > > > > > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote: > > > > > > > > > > > > > using new libgpiod / chardev driver, is there any way to get state of > > > > > > > > output? I mean one process sets it for example to 1 and another process > > > > > > > > reads this output state for example to show that on web page. > > > > > > > > > > I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO > > > > > chips may not allow this on H/W level and when reading they always > > > > > will get the value of Input Buffer (now imagine if the line is > > > > > configured as Output with Input being disconnected from the physical > > > > > pin). > > > > > > > > > > > > > Agreed. Userspace should know the value they set the output to, and so > > > > have no need to read it back. GPIO is not NVM. > > > Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0) > > > I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one. > > > > > > > No, no it is not RAM. > > > > And I have seen hardware where you can't read back the output. > > And so has Andy apparently. > > That is the problem - there is lots of hardware out there and we are > > trying to provide a consistent interface to inconsistent hardware. > OK, but if hw supports it why not provide it. And for hw without support keep it's value in memory? Or return to user space with errno indicating "no support"? No idea - I'm new here (by your definition) ;-). In general we do provide it where the hardware supports it, so for example typically reading back outputs works. I would guess the reason we don't provide a guarantee is that is that in most cases it isn't necessary, and to do so adds cost. Full on caching and error handling as you suggest would be overkill for most situations. Most writes to outputs don't get read back, so why waste resources caching them? And if you want to do the error handling you suggest you have to cache them - just in case, or you have to pre-get them to find out which lines need to be cached, but you can't do that without changing the line direction to output and you certainly can't do that autonomously, so the driver interface needs to be far more complex to probe the driver capabilities down to the line and in different modes. And you need to spend time doing that... Basically a can of worms. And the simple workaround is for the user to cache the value themselves if they need it and find their hardware doesn't support read back. So best effort is the most pragmatic and cost effective solution. (Hopefully Andy will chip in with the actual reason, which is probably something far more obvious ;-) As always, if you see a better way, submit a patch! Cheers, Kent. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2022-06-29 15:23 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-25 10:02 [libgpiod] bug: pull-up does not work Jiří Prchal 2022-03-25 14:57 ` Kent Gibson 2022-03-25 15:13 ` Jiří Prchal 2022-03-25 16:01 ` Kent Gibson 2022-03-28 7:12 ` Jiří Prchal 2022-03-28 8:08 ` Kent Gibson 2022-03-28 8:58 ` Jiří Prchal 2022-03-28 9:56 ` Kent Gibson 2022-06-28 13:08 ` [libgpiod] feature request: output state read and sustain Jiří Prchal 2022-06-29 7:23 ` Kent Gibson 2022-06-29 9:25 ` Jiří Prchal 2022-06-29 10:10 ` Kent Gibson 2022-06-29 10:27 ` Andy Shevchenko 2022-06-29 10:47 ` Kent Gibson 2022-06-29 10:58 ` Andy Shevchenko 2022-06-29 11:20 ` Kent Gibson 2022-06-29 11:55 ` Andy Shevchenko 2022-06-29 12:56 ` Bartosz Golaszewski 2022-06-29 15:22 ` Andy Shevchenko 2022-06-29 11:17 ` Jiří Prchal 2022-06-29 11:25 ` Kent Gibson 2022-06-29 11:48 ` Jiří Prchal 2022-06-29 12:51 ` Kent Gibson
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.