| Message ID | 1343219864-3040-2-git-send-email-dirk.behme@de.bosch.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jul 25, 2012 at 02:37:44PM +0200, Dirk Behme wrote: > From: Matthias Thomae <matthias.thomae@de.bosch.com> > > The GPIO controllers in the device tree are registered dynamically > via gpiochip_add and gpiochip_find_base in descending order (from > ARCH_NR_GPIO to 0). This change reorders the controllers in the > device tree (from gpio7 to gpio1) so that they finally appear in > ascending order after registration. > First of all, the device nodes in device tree are sorted in address order, and should be independent with Linux implementation. Secondly, I'm wondering why you care about the global gpio number, as gpio and associated interrupt should be addressed by port + offset. Regards, Shawn
> From: Shawn Guo [mailto:shawn.guo@linaro.org] > On Wed, Jul 25, 2012 at 02:37:44PM +0200, Dirk Behme wrote: > > From: Matthias Thomae <matthias.thomae@de.bosch.com> > > > > The GPIO controllers in the device tree are registered dynamically > > via gpiochip_add and gpiochip_find_base in descending order (from > > ARCH_NR_GPIO to 0). This change reorders the controllers in the > > device tree (from gpio7 to gpio1) so that they finally appear in > > ascending order after registration. > > > First of all, the device nodes in device tree are sorted in address > order, and should be independent with Linux implementation. > > Secondly, I'm wondering why you care about the global gpio number, > as gpio and associated interrupt should be addressed by port + offset. > > Regards, > Shawn Shawn, I care about the global number because it is used to access GPIOs from userspace via the Sysfs interface (see Documentation/gpio.txt). Without the 2 patches, the GPIOs are mapped this way: gpiochip_add: registered GPIOs 224 to 255 on device: 209c000.gpio gpiochip_add: registered GPIOs 192 to 223 on device: 20a0000.gpio gpiochip_add: registered GPIOs 160 to 191 on device: 20a4000.gpio gpiochip_add: registered GPIOs 128 to 159 on device: 20a8000.gpio gpiochip_add: registered GPIOs 96 to 127 on device: 20ac000.gpio gpiochip_add: registered GPIOs 64 to 95 on device: 20b0000.gpio gpiochip_add: registered GPIOs 32 to 63 on device: 20b4000.gpio With the patches, the mapping looks like this: gpiochip_add: registered GPIOs 192 to 223 on device: 20b4000.gpio gpiochip_add: registered GPIOs 160 to 191 on device: 20b0000.gpio gpiochip_add: registered GPIOs 128 to 159 on device: 20ac000.gpio gpiochip_add: registered GPIOs 96 to 127 on device: 20a8000.gpio gpiochip_add: registered GPIOs 64 to 95 on device: 20a4000.gpio gpiochip_add: registered GPIOs 32 to 63 on device: 20a0000.gpio gpiochip_add: registered GPIOs 0 to 31 on device: 209c000.gpio I.e. pin 0 on gpio1 is now accessed via /sys/class/gpio/gpio0 instead of /sys/class/gpio/gpio224. BR Matthias
On Mon, Jul 30, 2012 at 09:28:21AM +0200, Thomae Matthias (CM-AI/PJ-CF31) wrote: > I care about the global number because it is used to access GPIOs > from userspace via the Sysfs interface (see Documentation/gpio.txt). > Understood. But proposed the solution does not look right. I think we can define alias for gpio ports in device tree and have gpio driver identify the port via alias, and then we specify the numbers rather than having them dynamically allocated by gpio core.
On Mon, Jul 30, 2012 at 09:28:21AM +0200, Thomae Matthias (CM-AI/PJ-CF31) wrote: > I care about the global number because it is used to access GPIOs > from userspace via the Sysfs interface (see Documentation/gpio.txt). > Without the 2 patches, the GPIOs are mapped this way: > > gpiochip_add: registered GPIOs 224 to 255 on device: 209c000.gpio > gpiochip_add: registered GPIOs 192 to 223 on device: 20a0000.gpio > gpiochip_add: registered GPIOs 160 to 191 on device: 20a4000.gpio > gpiochip_add: registered GPIOs 128 to 159 on device: 20a8000.gpio > gpiochip_add: registered GPIOs 96 to 127 on device: 20ac000.gpio > gpiochip_add: registered GPIOs 64 to 95 on device: 20b0000.gpio > gpiochip_add: registered GPIOs 32 to 63 on device: 20b4000.gpio > > With the patches, the mapping looks like this: > > gpiochip_add: registered GPIOs 192 to 223 on device: 20b4000.gpio > gpiochip_add: registered GPIOs 160 to 191 on device: 20b0000.gpio > gpiochip_add: registered GPIOs 128 to 159 on device: 20ac000.gpio > gpiochip_add: registered GPIOs 96 to 127 on device: 20a8000.gpio > gpiochip_add: registered GPIOs 64 to 95 on device: 20a4000.gpio > gpiochip_add: registered GPIOs 32 to 63 on device: 20a0000.gpio > gpiochip_add: registered GPIOs 0 to 31 on device: 209c000.gpio > > I.e. pin 0 on gpio1 is now accessed via /sys/class/gpio/gpio0 > instead of /sys/class/gpio/gpio224. I think you're caring too much about the numbers you see within the Linux kernel... So what happens when your platform is built as part of a single zImage along side a platform needing all the 256 GPIOs? If the answer is "it doesn't work" you need to go back and re-evaluate what you're doing. Especially with DT, you shouldn't need to worry about the absolute GPIO numbering.
On 30.07.2012 16:24, Russell King - ARM Linux wrote: > On Mon, Jul 30, 2012 at 09:28:21AM +0200, Thomae Matthias (CM-AI/PJ-CF31) wrote: >> I care about the global number because it is used to access GPIOs >> from userspace via the Sysfs interface (see Documentation/gpio.txt). >> Without the 2 patches, the GPIOs are mapped this way: >> >> gpiochip_add: registered GPIOs 224 to 255 on device: 209c000.gpio >> gpiochip_add: registered GPIOs 192 to 223 on device: 20a0000.gpio >> gpiochip_add: registered GPIOs 160 to 191 on device: 20a4000.gpio >> gpiochip_add: registered GPIOs 128 to 159 on device: 20a8000.gpio >> gpiochip_add: registered GPIOs 96 to 127 on device: 20ac000.gpio >> gpiochip_add: registered GPIOs 64 to 95 on device: 20b0000.gpio >> gpiochip_add: registered GPIOs 32 to 63 on device: 20b4000.gpio >> >> With the patches, the mapping looks like this: >> >> gpiochip_add: registered GPIOs 192 to 223 on device: 20b4000.gpio >> gpiochip_add: registered GPIOs 160 to 191 on device: 20b0000.gpio >> gpiochip_add: registered GPIOs 128 to 159 on device: 20ac000.gpio >> gpiochip_add: registered GPIOs 96 to 127 on device: 20a8000.gpio >> gpiochip_add: registered GPIOs 64 to 95 on device: 20a4000.gpio >> gpiochip_add: registered GPIOs 32 to 63 on device: 20a0000.gpio >> gpiochip_add: registered GPIOs 0 to 31 on device: 209c000.gpio >> >> I.e. pin 0 on gpio1 is now accessed via /sys/class/gpio/gpio0 >> instead of /sys/class/gpio/gpio224. > > I think you're caring too much about the numbers you see within the Linux > kernel... > > So what happens when your platform is built as part of a single zImage > along side a platform needing all the 256 GPIOs? If the answer is "it > doesn't work" you need to go back and re-evaluate what you're doing. > > Especially with DT, you shouldn't need to worry about the absolute GPIO > numbering. Ok, thanks! If the patches we sent are not the way to go, maybe we need a better understanding then. Trying to learn something, I'd like to ask: From my understanding, a user in the _user_ space expects a 1:1 mapping: user touching /sys/class/gpio/gpio0 -> controls HW GPIO bank 1 pin 0 ... user touching /sys/class/gpio/gpio31 -> controls HW GPIO bank 1 pin 31 ... user touching /sys/class/gpio/gpio223 -> controls HW GPIO bank 7 pin 31 Is this understanding wrong? Or is there a way to achieve this with the existing DT logic? The above is what we tried to achieve with our patches. Without the patches, an unmodified DT and kernel gives us: user touching /sys/class/gpio/gpio0 -> n/a (*) ... user touching /sys/class/gpio/gpio32 -> controls HW GPIO bank 7 pin 0 ... user touching /sys/class/gpio/gpio224 -> controls HW GPIO bank 1 pin 0 ... user touching /sys/class/gpio/gpio255 -> controls HW GPIO bank 1 pin 31 (*) Note the offset of 32 due to ARCH_NR_GPIO is 256 while only 224 GPIOs are there. And the 'inverted' access order from bank 7 to 1. Many thanks for the help and best regards Dirk
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi index c25d495..7c908c1 100644 --- a/arch/arm/boot/dts/imx6q.dtsi +++ b/arch/arm/boot/dts/imx6q.dtsi @@ -276,30 +276,30 @@ interrupts = <0 55 0x04>; }; - gpio1: gpio@0209c000 { + gpio7: gpio@020b4000 { compatible = "fsl,imx6q-gpio", "fsl,imx31-gpio"; - reg = <0x0209c000 0x4000>; - interrupts = <0 66 0x04 0 67 0x04>; + reg = <0x020b4000 0x4000>; + interrupts = <0 78 0x04 0 79 0x04>; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; }; - gpio2: gpio@020a0000 { + gpio6: gpio@020b0000 { compatible = "fsl,imx6q-gpio", "fsl,imx31-gpio"; - reg = <0x020a0000 0x4000>; - interrupts = <0 68 0x04 0 69 0x04>; + reg = <0x020b0000 0x4000>; + interrupts = <0 76 0x04 0 77 0x04>; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; }; - gpio3: gpio@020a4000 { + gpio5: gpio@020ac000 { compatible = "fsl,imx6q-gpio", "fsl,imx31-gpio"; - reg = <0x020a4000 0x4000>; - interrupts = <0 70 0x04 0 71 0x04>; + reg = <0x020ac000 0x4000>; + interrupts = <0 74 0x04 0 75 0x04>; gpio-controller; #gpio-cells = <2>; interrupt-controller; @@ -316,30 +316,30 @@ #interrupt-cells = <2>; }; - gpio5: gpio@020ac000 { + gpio3: gpio@020a4000 { compatible = "fsl,imx6q-gpio", "fsl,imx31-gpio"; - reg = <0x020ac000 0x4000>; - interrupts = <0 74 0x04 0 75 0x04>; + reg = <0x020a4000 0x4000>; + interrupts = <0 70 0x04 0 71 0x04>; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; }; - gpio6: gpio@020b0000 { + gpio2: gpio@020a0000 { compatible = "fsl,imx6q-gpio", "fsl,imx31-gpio"; - reg = <0x020b0000 0x4000>; - interrupts = <0 76 0x04 0 77 0x04>; + reg = <0x020a0000 0x4000>; + interrupts = <0 68 0x04 0 69 0x04>; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; }; - gpio7: gpio@020b4000 { + gpio1: gpio@0209c000 { compatible = "fsl,imx6q-gpio", "fsl,imx31-gpio"; - reg = <0x020b4000 0x4000>; - interrupts = <0 78 0x04 0 79 0x04>; + reg = <0x0209c000 0x4000>; + interrupts = <0 66 0x04 0 67 0x04>; gpio-controller; #gpio-cells = <2>; interrupt-controller;