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.



>
> -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

Reply via email to