This patch is in openwrt tree: ramips/patches-3.8/0209-owrt-GPIO-add-gpio_export_with_name.patch
Looks like it supports naming them. On Thu, May 2, 2013 at 10:25 AM, Michel Stempin <[email protected]> wrote: > > > Le 02/05/2013 16:06, [email protected] a écrit : >> On Thu, May 2, 2013 at 9:49 AM, Michel Stempin >> <[email protected]> wrote: >>> Hi, >>> >>> It looks like the GPIOs are broken since the introduction of DTS for the >>> ramips architecture. >>> >>> In the DTS include file ("target/linux/ramips/dts/rt3050.dtsi" in my case, >>> by this is also true for the other ones), only the number of GPIOs for each >>> gpio-controller is defined, but not the GPIO base number for each chip. For >>> example: >>> >>> gpio0: gpio@600 { >>> compatible = "ralink,rt3052-gpio", >>> "ralink,rt2880-gpio"; >>> reg = <0x600 0x34>; >>> >>> gpio-controller; >>> #gpio-cells = <2>; >>> >>> ralink,num-gpios = <24>; >>> ralink,register-map = [ 00 04 08 0c >>> 20 24 28 2c >>> 30 34 ]; >>> >>> This part of DTS is handled by the ralink_gpio_probe() function added by >>> the "0130-GPIO-MIPS-ralink-adds-ralink-gpio-support.patch" file for the >>> ramips architecture, which sets the GPIO base number to -1 to get a >>> dynamically-allocated base GPIO number. >>> >>> This feature was introduced in Linux kernel 2.6.26-rc1 >>> (<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpio/gpiolib.c?id=8d0aab2f16c4fa170f32e7a74a52cd0122bbafef>), >>> but unfortunately, it is not applicable here, since to avoid using any >>> numbers that may have been explicitly assigned but not yet registered, this >>> dynamic allocation assigns GPIO numbers from the biggest number on down, >>> instead of from the smallest on up. >>> >>> This assignment is performed by function gpiochip_find_base() in the >>> kernel's "drivers/gpio/gpiolib.c" file, and as the same patch above defines >>> ARCH_NR_GPIOS to 128, this result in a base GPIO number of 128 - 24 = 104 >>> instead of the expected 0. >>> >>> Since changing the dynamic GPIO number feature in the kernel is out of >>> question as it would break the userspace ABIs >>> (<https://patchwork.kernel.org/patch/2084411/>), what is the best option to >>> get the GPIOs back working? >>> >>> My first guess would be to add a "ralink,base-gpio" property for each >>> gpio-controller chip to the DTS files for ralink... >>> >>> Any suggestions? >> >> Your code should not care about the assigned GPIO number. >> >> gpio_ebi_i2stx_0: gpio@13003040 { >> #gpio-cells = <2>; >> compatible = "nxp,lpc31xx-gpio"; >> reg = <0x13003040 0x40>; >> gpio-controller; >> }; >> gpio_spi: gpio@13003240 { >> #gpio-cells = <2>; >> compatible = "nxp,lpc31xx-gpio"; >> reg = <0x13003240 0x40>; >> gpio-controller; >> }; >> >> >> Spi device that uses the GPIO... >> >> spi@15002000 { >> gpios = <&gpio_spi 4 0 /* chip selects */ >> &gpio_ebi_i2stx_0 3 0>; >> s25sl032a@0 { >> compatible = "code,s25sl032a"; >> reg = <0>; >> spi-max-frequency = <1000000>; >> }; >> }; >> >> then use something like: >> >> gpio = of_get_gpio_flags(pdev->dev.of_node, i, &flags); >> or >> cs_gpio = of_get_named_gpio(pdev->dev.of_node, "cs-gpios", i); >> >> To attach your gpio. > > What about the /sys/class/gpio user interface, then? > > I get a gpiochip124 with a gpiochip124/base = 124 in my case... > > -Michel >> >> >> >>> >>> -Michel >>> _______________________________________________ >>> openwrt-devel mailing list >>> [email protected] >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> >> >> >> -- >> Jon Smirl >> [email protected] >> _______________________________________________ >> openwrt-devel mailing list >> [email protected] >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Jon Smirl [email protected] _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
