Le 02/05/2013 16:39, jonsm...@gmail.com a écrit :
> 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.

Ok, this works for static GPIO naming (like calls to gpio_export() in old board 
support files), but what about dynamically exported GPIOs by the user, like 
with:

echo 9 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio9/direction
echo 1 > /sys/class/gpio/gpio9/value

-Michel

> 
> On Thu, May 2, 2013 at 10:25 AM, Michel Stempin
> <michel.stem...@wanadoo.fr> wrote:
>>
>>
>> Le 02/05/2013 16:06, jonsm...@gmail.com a écrit :
>>> On Thu, May 2, 2013 at 9:49 AM, Michel Stempin
>>> <michel.stem...@wanadoo.fr> 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
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
>>>
>>>
>>> --
>>> Jon Smirl
>>> jonsm...@gmail.com
>>> _______________________________________________
>>> 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
> 
> 
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to