[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Dirk Behme]

From: Matthias Thomae <matthias.thomae@de.bosch.com>

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 <matthias.thomae@de.bosch.com>
CC: Shawn Guo <shawn.guo@linaro.org>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b25c9d3..5e4cde3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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
 	default 0
 	help
 	  Maximum number of GPIOs in the system.
-- 
1.7.0.4

[PATCH 2/2] ARM: dts: imx6q: Invert the GPIO controller order

[Dirk Behme]

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.

Signed-off-by: Matthias Thomae <matthias.thomae@de.bosch.com>
CC: Shawn Guo <shawn.guo@linaro.org>
---
 arch/arm/boot/dts/imx6q.dtsi |   36 ++++++++++++++++++------------------
 1 files changed, 18 insertions(+), 18 deletions(-)

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 at 0209c000 {
+			gpio7: gpio at 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 at 020a0000 {
+			gpio6: gpio at 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 at 020a4000 {
+			gpio5: gpio at 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 at 020ac000 {
+			gpio3: gpio at 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 at 020b0000 {
+			gpio2: gpio at 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 at 020b4000 {
+			gpio1: gpio at 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;
-- 
1.7.0.4

[PATCH 2/2] ARM: dts: imx6q: Invert the GPIO controller order

[Shawn Guo]

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

[PATCH 2/2] ARM: dts: imx6q: Invert the GPIO controller order

[Thomae Matthias (CM-AI/PJ-CF31)]

> From: Shawn Guo [mailto:shawn.guo at 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

[PATCH 2/2] ARM: dts: imx6q: Invert the GPIO controller order

[Shawn Guo]

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.

-- 
Regards,
Shawn

[PATCH 2/2] ARM: dts: imx6q: Invert the GPIO controller order

[Russell King - ARM Linux]

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.

[PATCH 2/2] ARM: dts: imx6q: Invert the GPIO controller order

[Dirk Behme]

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

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Fabio Estevam]

On Wed, Jul 25, 2012 at 9:37 AM, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> From: Matthias Thomae <matthias.thomae@de.bosch.com>
>
> 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 <matthias.thomae@de.bosch.com>

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

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Dirk Behme]

On 25.07.2012 16:12, Fabio Estevam wrote:
> On Wed, Jul 25, 2012 at 9:37 AM, Dirk Behme<dirk.behme@de.bosch.com>  wrote:
>> From: Matthias Thomae<matthias.thomae@de.bosch.com>
>>
>> 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<matthias.thomae@de.bosch.com>
>
> Looks like a typo in the subject. It should be 224, right?

Yes.

Any further comments to be fixed in v2?

Best regards

Dirk

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Shawn Guo]

On Wed, Jul 25, 2012 at 02:37:43PM +0200, Dirk Behme wrote:
> From: Matthias Thomae <matthias.thomae@de.bosch.com>
> 
> 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 <matthias.thomae@de.bosch.com>
> CC: Shawn Guo <shawn.guo@linaro.org>
> ---
>  arch/arm/Kconfig |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b25c9d3..5e4cde3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -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?

-- 
Regards,
Shawn

>  	default 0
>  	help
>  	  Maximum number of GPIOs in the system.
> -- 
> 1.7.0.4
> 

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Dirk Behme]

On 28.07.2012 15:32, Shawn Guo wrote:
> On Wed, Jul 25, 2012 at 02:37:43PM +0200, Dirk Behme wrote:
>> From: Matthias Thomae<matthias.thomae@de.bosch.com>
>>
>> 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<matthias.thomae@de.bosch.com>
>> CC: Shawn Guo<shawn.guo@linaro.org>
>> ---
>>   arch/arm/Kconfig |    1 +
>>   1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index b25c9d3..5e4cde3 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -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).

Best regards

Dirk

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Shawn Guo]

On Sun, Jul 29, 2012 at 06:18:21PM +0200, Dirk Behme wrote:
> 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.  That's why I'm not so excited about the patch.

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.

-- 
Regards,
Shawn

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Dirk Behme]

On 30.07.2012 03:14, Shawn Guo wrote:
> On Sun, Jul 29, 2012 at 06:18:21PM +0200, Dirk Behme wrote:
>> 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.

It's my understanding that the ARCH_NR_GPIO Kconfig was introduced 
recently for optimization/conversion/cleanup reasons. So from my point 
of view it's in a first step better to use it for iMX6 than ignoring 
this optimization/conversion/cleanup.

But yes, it's even better to enable it for imx3/imx5, too. As I don't 
know these platforms, two questions:

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

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

Best regards

Dirk

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Shawn Guo]

On Mon, Jul 30, 2012 at 08:40:58AM +0200, Dirk Behme wrote:
> - 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.

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

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

> But what's the issue using a matching number if possible?
> 
At least for IMX, it does not help that much.

-- 
Regards,
Shawn

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Dirk Behme]

On 30.07.2012 10:46, Shawn Guo wrote:
> On Mon, Jul 30, 2012 at 08:40:58AM +0200, Dirk Behme wrote:
>> - 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.

I understood

http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01565.html

that the goal is to not use the headers any more. But I might have 
misunderstood that ...

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

Sounds like 7 is a good max number then, thanks!

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

Hmm, maybe they just have all more than 256 and we are the first with 
less? Anyway, I'm not sure why smaller/bigger should be important here. 
I would feel that the goal should be to configure the correct number if 
possible, independent of smaller/bigger.

Best regards

Dirk

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 04:46:07PM +0800, Shawn Guo wrote:
> On Mon, Jul 30, 2012 at 08:40:58AM +0200, Dirk Behme wrote:
> > - 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... :)

[PATCH 1/2] ARM: i.MX6: set ARCH_NR_GPIO to 244

[Shawn Guo]

On Mon, Jul 30, 2012 at 03:29:08PM +0100, Russell King - ARM Linux wrote:
> 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... :)

Right.  I was wrong on that.  But I still maintain my position that
there is no much point to define CONFIG_ARCH_NR_GPIO as 224 for space
saving.  I would rather not use it for IMX until we have an IMX SoC
implementing more than 256 gpio.

-- 
Regards,
Shawn