ARM: i.MX6: set ARCH_NR_GPIO to 244

From: Matthias Thomae <[email protected]>

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.

From: Shawn Guo [mailto:shawn.guo at linaro.org]

Quoted 8 lines · Dirk Behme

From: Matthias Thomae <[email protected]>

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

I care about the global number because it is used to access GPIOs from userspace via the Sysfs interface (see Documentation/gpio.txt).

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.

Quoted 22 lines · 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

Quoted 2 lines

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.

From: Matthias Thomae <[email protected]>

Set ARCH_NR_GPIO for the i.MX6 processor family, which has 7 GPIO controllers with 32 signals each. The default of 256 GPIOs wastes some static table space as explained in Documentation/gpio.txt.

Signed-off-by Matthias Thomae <[email protected]>

Quoted 7 lines · Dirk Behme

From: Matthias Thomae<[email protected]>

Set ARCH_NR_GPIO for the i.MX6 processor family, which has 7 GPIO controllers with 32 signals each. The default of 256 GPIOs wastes some static table space as explained in Documentation/gpio.txt.

Signed-off-by Matthias Thomae<[email protected]>

Looks like a typo in the subject. It should be 224, right?

From: Matthias Thomae <[email protected]>

Set ARCH_NR_GPIO for the i.MX6 processor family, which has 7 GPIO controllers with 32 signals each. The default of 256 GPIOs wastes some static table space as explained in Documentation/gpio.txt.

Signed-off-by Matthias Thomae <[email protected]>

CC Shawn Guo <[email protected]>

---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

arch/arm/Kconfig +0 -0

index b25c9d3..5e4cde3 100644

arch/arm/Kconfig +0 -0

 	default 0
 	help
 	  Maximum number of GPIOs in the system.

Signature · 1 line

1.7.0.4

Quoted 12 lines · Dirk Behme

From: Matthias Thomae<[email protected]>

Set ARCH_NR_GPIO for the i.MX6 processor family, which has 7 GPIO controllers with 32 signals each. The default of 256 GPIOs wastes some static table space as explained in Documentation/gpio.txt.

Signed-off-by Matthias Thomae<[email protected]>

CC Shawn Guo<[email protected]>

---
  arch/arm/Kconfig |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

arch/arm/Kconfig config ARCH_NR_GPIO · line 1629

Quoted 9 lines

arch/arm/Kconfig +1 -0

index b25c9d3..5e4cde3 100644
@@ -1626,6 +1626,7 @@ config ARCH_NR_GPIO
  	default 355 if ARCH_U8500
  	default 264 if MACH_H4700
  	default 512 if SOC_OMAP5
+	default 224 if SOC_IMX6Q

So what if we build imx_v6_v7_defconfig with IMX6Q deselected?

Hmm, sorry if I missed anything, but how is adding a 'default .. SOC_IMX6Q' related to any defconfig? If you want to deselect SOC_IMX6Q using the way you like you'll get the standard 256 (if I remember correctly).

Quoted 5 lines · Dirk Behme

Hmm, sorry if I missed anything, but how is adding a 'default .. SOC_IMX6Q' related to any defconfig? If you want to deselect SOC_IMX6Q using the way you like you'll get the standard 256 (if I remember correctly).

I'm essentially questioning about the point of the patch. It intends to save a little space for imx6q build without caring about imx3 and imx5. That said, when imx6q is excluded from the build, we are still wasting those space.

Looking at current users of this definition, you will find all of them are defining a number bigger than 256 for extending the maximum number. It might be a sign that having a gpio array which is a little bigger than necessary is not a concern on machines today.

- Do you like to propose a better macro than SOC_IMX6Q to cover imx3/imx6, too?

- Do imx3 and imx5 have the same GPIO number like imx6? I.e. 7 banks with 32 pins == 224 GPIOs?

Quoted 4 lines

Looking at current users of this definition, you will find all of them are defining a number bigger than 256 for extending the maximum number. It might be a sign that having a gpio array which is a little bigger than necessary is not a concern on machines today.

Or it might be a sign that they *have* more than 256? I don't know.

But what's the issue using a matching number if possible?

Quoted 3 lines · Dirk Behme

- Do you like to propose a better macro than SOC_IMX6Q to cover imx3/imx6, too?

No, I do not see the need of this. CONFIG_ARCH_NR_GPIO is not the only way to overwrite the default number. We can define ARCH_NR_GPIOS to the number we want in IMX platform headers.

Quoted 3 lines

- Do imx3 and imx5 have the same GPIO number like imx6? I.e. 7 banks with 32 pins == 224 GPIOs?

imx31, imx35: 3 banks
imx51: 4 banks
imx53: 7 banks

Quoted 5 lines

Quoted 4 lines

Looking at current users of this definition, you will find all of them are defining a number bigger than 256 for extending the maximum number. It might be a sign that having a gpio array which is a little bigger than necessary is not a concern on machines today.

Or it might be a sign that they *have* more than 256? I don't know.

Yes. I was actually saying that there is no platforms defining the Kconfig symbol smaller than 256 to save the space.

Quoted 3 lines · Dirk Behme

- Do you like to propose a better macro than SOC_IMX6Q to cover imx3/imx6, too?

No, I do not see the need of this. CONFIG_ARCH_NR_GPIO is not the only way to overwrite the default number. We can define ARCH_NR_GPIOS to the number we want in IMX platform headers.

Don't do that. CONFIG_ARCH_NR_GPIO is there so that we can consolidate out as much crap from mach/gpio.h as possible. Either use it now, or I will patch you to make you use it. Either way, you will end up using it... :)