Re: gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
On 10/19/22 05:51, Lukas Zeller wrote: Hi, Lukas, thanks for this. I've read through everything and I agree with your concerns. I'll note also that Linus W's commentary is from 2018. On 19 Oct 2022, at 08:55, Petr Štetiar wrote: IMO there should be `ugpiod` daemon available over ubus, probably written in ucode using libgpiod bindings. It should provide ubus events for GPIO inputs and should be able to control GPIO outputs using ubus calls. What would that mean for performance, compared to more direct call chains as when using legacy /sys/class/gpio and current libgpiod? I suspect it would be much slower via an extra daemon. Regarding performance, this is a practical concern. In one case using a GPIO- driven 3-color LED, using explicit user-space tools (albeit a clunky vendor program), to blink, there was a enough of a delay between the blinks to give a disconcerting display when trying to blink white. I'm sure there's a better way to do this, but changing the code to direct file access to the GPIOs produced a more satisfactory result. And I still haven't seen a rationale for the "non-fixed" base - I understand there's probably a desire for abstraction somewhere, but figuring out offsets becomes a hassle. I get that some boards have some wacky GPIO assignments due to chip design, but this is surely a DTS concern. I'm sure also it's trivial to extend the legacy GPIO export function to export named GPIOs too (if it doesn't already, I haven't looked). So for the moment, there doesn't seem to be general-purpose solution in OpenWrt, especially for script use. I'll gladly migrate to that if there is one in future, but I think for now I need to stick to my patch and named GPIO exports in the DTS. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
Hi, > On 19 Oct 2022, at 08:55, Petr Štetiar wrote: > > IMO there should be `ugpiod` daemon available over ubus, probably written in > ucode using libgpiod bindings. It should provide ubus events for GPIO inputs > and should be able to control GPIO outputs using ubus calls. What would that mean for performance, compared to more direct call chains as when using legacy /sys/class/gpio and current libgpiod? I suspect it would be much slower via an extra daemon. But I see a basic underlying question here: how to look at GPIOs in the general context of OpenWrt? - From a systems designers perspective, a GPIO is a I/O pin of the SoC or one of the peripheral chips in the system which has no specific function determined by the silicon, but gets one by the board/device design. This is the main perspective in Linux, and DT is the layer to "wire" the GPIOs for the specific task to run a certain board or device. - From the perspective of people who build educational or experimental devices, where reconfiguring GPIOs is a essential part of the USER experience, changing DT bindings (be it just `gpio-line-names`) is not a viable solution. Especially not since the mechanism to do so without rebuilding firmware images - dynamically loading DT overlays - is not approved of as well [1]. For this perspective, deprecating old GPIO numbering and retiring spi-gpio-custom et. al. drivers with no real substitute is a serious step backwards, and a reason not to upgrade to newer versions. I see that the first of the two perspectives is the correct one for the main usage of OpenWrt, an OS for network boxes and boards, and obviously has priority. However, OpenWrt is also a very good base for other uses, maybe summarizable as "user configurable hardware controllers" (as said, education, but also controllers for exhibitions and art installations - one of my primary applications). After years using and trying to contribute to OpenWrt for this use case I still don't really understand the sentinents of core OpenWrt towards this sideline - is it rather seen as a distracting nuisance or an opportunity? ;-) Somehow I need to have a clearer view on this meta level to do more than just patch the missing things for myself. I would like to not only profit, but also contribute, but can do only so from and for the second of the two perspectives above, because that's what I understand and work with. Any thoughts? Best Regards Lukas [1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037164.html > Bjørn Mork [2022-10-19 08:24:44]: > >> Sergio Paracuellos via openwrt-devel >> writes: >> >>> This is the reason we have 'gpio-line-names' property so you can set >>> up names for your pins and use it together with actual user space >>> tools libgpiod and gpiod. Any other gpio user space library is >>> considered deprecated in these days. >> >> Interesting. This property doesn't seem to be used much in OpenWrt if >> my grep foo is good. It should probably be added at least to every >> system where we want to access GPIOs from userspace? > > Yes, that is my[1] understanding as well. > > 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376 > > -- ynezz signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
Petr Štetiar writes: >> Interesting. This property doesn't seem to be used much in OpenWrt if >> my grep foo is good. It should probably be added at least to every >> system where we want to access GPIOs from userspace? > > Yes, that is my[1] understanding as well. > > 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376 If my qucik read of that is correct, then the main reason it didn't go anywhere was because it was about libgpiod transition. A simple start by adding properties to the board DTs where we already have a named userspace GPIO in for example /etc/board.d/03_gpio_switches should be a no brainer, or? Having the names in the device tree won't force any userspace changes, but will allow them to happen later. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
gpio fiddling from userspace [Was: Re: gpio-mt7621 offset fix for 5.10 kernel series]
Lukas Zeller [2022-10-18 23:10:48]: Hi, > I did investigate this in June on this list [1] and in the openwrt forum [2] > and tried to ask some questions about the right way to handle this, but > apparently it did not echo for some reason back then. IMO there should be `ugpiod` daemon available over ubus, probably written in ucode using libgpiod bindings. It should provide ubus events for GPIO inputs and should be able to control GPIO outputs using ubus calls. Bjørn Mork [2022-10-19 08:24:44]: > Sergio Paracuellos via openwrt-devel > writes: > > > This is the reason we have 'gpio-line-names' property so you can set > > up names for your pins and use it together with actual user space > > tools libgpiod and gpiod. Any other gpio user space library is > > considered deprecated in these days. > > Interesting. This property doesn't seem to be used much in OpenWrt if > my grep foo is good. It should probably be added at least to every > system where we want to access GPIOs from userspace? Yes, that is my[1] understanding as well. 1. https://github.com/openwrt/openwrt/pull/1366#issuecomment-444177376 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
Sergio Paracuellos via openwrt-devel writes: > This is the reason we have 'gpio-line-names' property so you can set > up names for your pins and use it together with actual user space > tools libgpiod and gpiod. Any other gpio user space library is > considered deprecated in these days. Interesting. This property doesn't seem to be used much in OpenWrt if my grep foo is good. It should probably be added at least to every system where we want to access GPIOs from userspace? "git grep ucidef_add_gpio_switch" shows lots of good candidates... For reference, there kernel docs describes 'gpio-line-names' as Optionally, a GPIO controller may have a "gpio-line-names" property. This is an array of strings defining the names of the GPIO lines going out of the GPIO controller. This name should be the most meaningful producer name for the system, such as a rail name indicating the usage. Package names such as pin name are discouraged: such lines have opaque names (since they are by definition generic purpose) and such names are usually not very helpful. For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are reasonable line names as they describe what the line is used for. "GPIO0" is not a good name to give to a GPIO line. Placeholders are discouraged: rather use the "" (blank string) if the use of the GPIO line is undefined in your design. The names are assigned starting from line offset 0 from left to right from the passed array. An incomplete array (where the number of passed named are less than ngpios) will still be used up until the last provided valid line index. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
On Wed, Oct 19, 2022 at 6:02 AM Sergio Paracuellos wrote: > > On Wed, Oct 19, 2022 at 1:10 AM Rosen Penev wrote: > > > > On Tue, Oct 18, 2022 at 3:50 PM Peter Naulls wrote: > > > > > > On 10/18/22 17:10, Lukas Zeller wrote: > > > . > > > > > > > > Just not any more - the mt7621 had this too. I currently patch it back > > > > into > > > > 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] > > > > > > > > I can follow the rationale to get rid of legacy GPIOs, but in the > > > > context > > > > of experimenting platforms, where GPIOs are a thing to work with in > > > > user space, there's just no real replacement yet (see details in > > > > [1],[2]). > > > > > > Yes, I see. > > > > > > I have a mix of C and scripted GPIO access in my setup, and certainly I > > > can > > > move to libgpiod for that - or just just access them as files with > > > named GPIOs as setup per the DTS. > > Let's CC Sergio, who upstreamed this driver. > > For kernel developers, setting base in GPIOs is a no go. You have to > let the kernel to assign its numbers so you can handle different GPIO > layouts with multiple chips. > This is the reason we have 'gpio-line-names' property so you can set > up names for your pins and use it together with actual user space > tools libgpiod and gpiod. Any other gpio user space library is > considered deprecated in these days. See Linus comments about base in review: https://marc.info/?l=linux-gpio&m=152845919029921&w=1 Thanks, Sergio Paracuellos > > Best regards, > Sergio Paracuellos > > > > > > > I do see the GPIO shell examples in the OpenWrt wiki, but the code needs > > > more work to deal with multiple banks, and it just makes figuring out > > > the GPIO number to use more clunky without any good cause. > > > > > > Now, the numbered GPIOs really are just for debug in my system, the > > > actual code will use the named ones, but still. > > > > > > Is the long-term intent for shell scripting to instead use the libgpiod > > > tools? > > > > > > https://openwrt.org/docs/techref/hardware/port.gpio > > > > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Wed, Oct 19, 2022 at 1:10 AM Rosen Penev wrote: > > On Tue, Oct 18, 2022 at 3:50 PM Peter Naulls wrote: > > > > On 10/18/22 17:10, Lukas Zeller wrote: > > . > > > > > > Just not any more - the mt7621 had this too. I currently patch it back > > > into > > > 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] > > > > > > I can follow the rationale to get rid of legacy GPIOs, but in the context > > > of experimenting platforms, where GPIOs are a thing to work with in > > > user space, there's just no real replacement yet (see details in [1],[2]). > > > > Yes, I see. > > > > I have a mix of C and scripted GPIO access in my setup, and certainly I can > > move to libgpiod for that - or just just access them as files with > > named GPIOs as setup per the DTS. > Let's CC Sergio, who upstreamed this driver. For kernel developers, setting base in GPIOs is a no go. You have to let the kernel to assign its numbers so you can handle different GPIO layouts with multiple chips. This is the reason we have 'gpio-line-names' property so you can set up names for your pins and use it together with actual user space tools libgpiod and gpiod. Any other gpio user space library is considered deprecated in these days. Best regards, Sergio Paracuellos > > > > I do see the GPIO shell examples in the OpenWrt wiki, but the code needs > > more work to deal with multiple banks, and it just makes figuring out > > the GPIO number to use more clunky without any good cause. > > > > Now, the numbered GPIOs really are just for debug in my system, the > > actual code will use the named ones, but still. > > > > Is the long-term intent for shell scripting to instead use the libgpiod > > tools? > > > > https://openwrt.org/docs/techref/hardware/port.gpio > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
On Tue, Oct 18, 2022 at 3:50 PM Peter Naulls wrote: > > On 10/18/22 17:10, Lukas Zeller wrote: > . > > > > Just not any more - the mt7621 had this too. I currently patch it back into > > 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] > > > > I can follow the rationale to get rid of legacy GPIOs, but in the context > > of experimenting platforms, where GPIOs are a thing to work with in > > user space, there's just no real replacement yet (see details in [1],[2]). > > Yes, I see. > > I have a mix of C and scripted GPIO access in my setup, and certainly I can > move to libgpiod for that - or just just access them as files with > named GPIOs as setup per the DTS. Let's CC Sergio, who upstreamed this driver. > > I do see the GPIO shell examples in the OpenWrt wiki, but the code needs > more work to deal with multiple banks, and it just makes figuring out > the GPIO number to use more clunky without any good cause. > > Now, the numbered GPIOs really are just for debug in my system, the > actual code will use the named ones, but still. > > Is the long-term intent for shell scripting to instead use the libgpiod > tools? > > https://openwrt.org/docs/techref/hardware/port.gpio > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
On 10/18/22 17:10, Lukas Zeller wrote: . Just not any more - the mt7621 had this too. I currently patch it back into 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] I can follow the rationale to get rid of legacy GPIOs, but in the context of experimenting platforms, where GPIOs are a thing to work with in user space, there's just no real replacement yet (see details in [1],[2]). Yes, I see. I have a mix of C and scripted GPIO access in my setup, and certainly I can move to libgpiod for that - or just just access them as files with named GPIOs as setup per the DTS. I do see the GPIO shell examples in the OpenWrt wiki, but the code needs more work to deal with multiple banks, and it just makes figuring out the GPIO number to use more clunky without any good cause. Now, the numbered GPIOs really are just for debug in my system, the actual code will use the named ones, but still. Is the long-term intent for shell scripting to instead use the libgpiod tools? https://openwrt.org/docs/techref/hardware/port.gpio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
Hi Peter and Martin, > On 18 Oct 2022, at 22:02, Peter Naulls wrote: > > On 10/18/22 15:55, Martin Blumenstingl wrote: >> [...] my understanding is that the recommended way for >> accessing GPIOs from userspace (in case that's what you need) should >> be done through libgpiod. > > Thanks for pointing me at this. Of course, I don't keep tabs on all the > kernel development. I did investigate this in June on this list [1] and in the openwrt forum [2] and tried to ask some questions about the right way to handle this, but apparently it did not echo for some reason back then. > I will say the following though: > > It looks a bit odd - the 416 is arbitrary at best, but I'm sure it comes > from some calculation. The MT76xx GPIO has 3 banks with 32 GPIOs each, and the driver initializes them in the order 0,1,2. The automatic lecagcy GPIO number assignment works by allocating numbers down from 512 in chunks of 32. So bank 0 gets 512-32 = 480 as base, bank1 gets 448 and bank2 gets 416. But GPIOs *within* the chunks are counted upwards, so you'll get a very unintuitive zigzag mapping when comparing with the pin names in the datasheet. > All/most of the other ramips use the ramips GPIO driver instead, which > does specify the base, although that's in the the DTS; there's no > facility for that in the mt7621 setup at present. Just not any more - the mt7621 had this too. I currently patch it back into 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] I can follow the rationale to get rid of legacy GPIOs, but in the context of experimenting platforms, where GPIOs are a thing to work with in user space, there's just no real replacement yet (see details in [1],[2]). So IMHO, at least the "base" of property should stay for a while. Best Regards Lukas [1] http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038912.html [2] https://forum.openwrt.org/t/state-of-userland-access-to-gpio-based-hardware/130505 [3] https://plan44.ch/downloads/v22.03-metapatch-readd-of-base-to-gpio-mt7621.patch signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
On 10/18/22 15:55, Martin Blumenstingl wrote: Hello Peter, On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls wrote: Looks like there was some code loss when the driver came from an earlier kernel series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that number, I don't know): You should also explain the problem with this behavior (if there's any). Upstream kernel doc [0] mentions: * @base: identifies the first GPIO number handled by this chip; * or, if negative during registration, requests dynamic ID allocation. * DEPRECATION: providing anything non-negative and nailing the base * offset of GPIO chips is deprecated. Please pass -1 as base to * let gpiolib select the chip base in all possible cases. We want to * get rid of the static GPIO number space in the long run. I never used it but my understanding is that the recommended way for accessing GPIOs from userspace (in case that's what you need) should be done through libgpiod. Thanks for pointing me at this. Of course, I don't keep tabs on all the kernel development. I will say the following though: It looks a bit odd - the 416 is arbitrary at best, but I'm sure it comes from some calculation. All/most of the other ramips use the ramips GPIO driver instead, which does specify the base, although that's in the the DTS; there's no facility for that in the mt7621 setup at present. I ended up using named GPIO mappings set up in the DTS, which appears to be OK. I was chasing some additional GPIO issues vs what I had working on an earlier kernel series - it didn't immediately help, but it was an obvious inconsistency. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello Peter, On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls wrote: > > > Looks like there was some code loss when the driver came from an earlier > kernel > series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that > number, I don't know): You should also explain the problem with this behavior (if there's any). Upstream kernel doc [0] mentions: * @base: identifies the first GPIO number handled by this chip; * or, if negative during registration, requests dynamic ID allocation. * DEPRECATION: providing anything non-negative and nailing the base * offset of GPIO chips is deprecated. Please pass -1 as base to * let gpiolib select the chip base in all possible cases. We want to * get rid of the static GPIO number space in the long run. I never used it but my understanding is that the recommended way for accessing GPIOs from userspace (in case that's what you need) should be done through libgpiod. Best regards, Martin [0] https://elixir.bootlin.com/linux/v4.14.295/source/include/linux/gpio/driver.h#L48 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
gpio-mt7621 offset fix for 5.10 kernel series
Looks like there was some code loss when the driver came from an earlier kernel series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that number, I don't know): --- a/drivers/gpio/gpio-mt7621.c2022-10-18 15:03:42.596454871 -0400 +++ b/drivers/gpio/gpio-mt7621.c2022-10-18 13:51:23.628305673 -0400 @@ -234,6 +234,7 @@ return ret; } +rg->chip.base = rg->bank * MTK_BANK_WIDTH; rg->chip.of_gpio_n_cells = 2; rg->chip.of_xlate = mediatek_gpio_xlate; rg->chip.label = devm_kasprintf(dev, GFP_KERNEL, "%s-bank%d", I'm using 5.10 in the current OpenWrt 22.03. Before # ls -l /sys/class/gpio/gpiochip4* lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip416 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio6 lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip448 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio8 lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip480 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio0 After: # ls -l /sys/class/gpio/ --w---1 root root 4096 Jan 1 1970 export lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip0 lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip32 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip32 lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip64 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip64 --w---1 root root 4096 Jan 1 1970 unexport Which is consistent with what I had in 4.14 series. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
