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?
-Michel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
