pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

PATCH Superseded Paul Parsons 5 participants 8 messages Dec 12, 2011 – Jan 5, 2012

Subsystems (3)

Arm (32-bit) Arm sub-architectures PXA2xx/PXA3xx support

lore

Share & tools

lore

Paul Parsons

author

2011-12-12 22:21 UTC #0 lore raw

PATCH 1/1 pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

linux-2.6.32 changed the values of PXA_GPIO_IRQ_BASE and PXA_GPIO_IRQ_NUM from 64/128 to 96/192. This has broken the hx4700 platform, for example its PCMCIA/CF driver. The 9 EGPIO GPIOs have become numbered 256..264, and consequently fail the gpio_is_valid() test in gpiolib.c (which limits GPIOs to the range 0..255). This patch reverts the values of PXA_GPIO_IRQ_BASE and PXA_GPIO_IRQ_NUM to their previous linux-2.6.31 values for the hx4700 platform only.

Signed-off-by Paul Parsons <[email protected]>

---

arch/arm/mach-pxa/include/mach/irqs.h +5 -0

diff -uprN clean-3.2-rc5/arch/arm/mach-pxa/include/mach/irqs.h linux-3.2-rc5/arch/arm/mach-pxa/include/mach/irqs.h
@@ -87,8 +87,13 @@
 #define IRQ_PXA955_MMC3	PXA_IRQ(75)	/* MMC3 Controller (PXA955) */
 #define IRQ_U2P		PXA_IRQ(93)	/* USB PHY D+/D- Lines (PXA935) */
 
+#ifdef CONFIG_MACH_H4700
+#define PXA_GPIO_IRQ_BASE	PXA_IRQ(64)
+#define PXA_GPIO_IRQ_NUM	(128)
+#else
 #define PXA_GPIO_IRQ_BASE	PXA_IRQ(96)
 #define PXA_GPIO_IRQ_NUM	(192)
+#endif
 
 #define GPIO_2_x_TO_IRQ(x)	(PXA_GPIO_IRQ_BASE + (x))
 #define IRQ_GPIO(x)	(((x) < 2) ? (IRQ_GPIO0 + (x)) : GPIO_2_x_TO_IRQ(x))

Philipp Zabel

2011-12-21 14:12 UTC #1 lore raw

PATCH 1/1 pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

Hello Paul,

Quoted 21 lines · Paul Parsons

linux-2.6.32 changed the values of PXA_GPIO_IRQ_BASE and PXA_GPIO_IRQ_NUM from 64/128 to 96/192. This has broken the hx4700 platform, for example its PCMCIA/CF driver. The 9 EGPIO GPIOs have become numbered 256..264, and consequently fail the gpio_is_valid() test in gpiolib.c (which limits GPIOs to the range 0..255). This patch reverts the values of PXA_GPIO_IRQ_BASE and PXA_GPIO_IRQ_NUM to their previous linux-2.6.31 values for the hx4700 platform only.
Signed-off-by Paul Parsons <[email protected]>
---
diff -uprN clean-3.2-rc5/arch/arm/mach-pxa/include/mach/irqs.h linux-3.2-rc5/arch/arm/mach-pxa/include/mach/irqs.h
arch/arm/mach-pxa/include/mach/irqs.h 2011-12-12 15:21:09.770483920 +0000 renamed from arch/arm/mach-pxa/include/mach/irqs.h 2011-12-09 23:09:32.000000000 +0000 +0 -0
@@ -87,8 +87,13 @@
?#define IRQ_PXA955_MMC3 ? ? ? ?PXA_IRQ(75) ? ? /* MMC3 Controller (PXA955) */ ?#define IRQ_U2P ? ? ? ? ? ? ? ?PXA_IRQ(93) ? ? /* USB PHY D+/D- Lines (PXA935) */
arch/arm/mach-pxa/include/mach/irqs.h 2011-12-12 15:21:09.770483920 +0000 renamed from arch/arm/mach-pxa/include/mach/irqs.h 2011-12-09 23:09:32.000000000 +0000 +4 -0
+#ifdef CONFIG_MACH_H4700
+#define PXA_GPIO_IRQ_BASE ? ? ?PXA_IRQ(64)
+#define PXA_GPIO_IRQ_NUM ? ? ? (128)
+#else

Quoted 3 lines

?#define PXA_GPIO_IRQ_BASE ? ? ?PXA_IRQ(96)
?#define PXA_GPIO_IRQ_NUM ? ? ? (192)
+#endif

machine specific definitions were removed from mach/irqs.h in commits 0dc726bb264ca5ecfdfab94a6937e0e9b9b26f64 ([ARM] pxa: move board board IRQ definitions out of irqs.h) and 6ac6b817f3f4c23c5febd960d8deb343e13af5f3 (ARM: pxa: encode IRQ number into .nr_irqs).
I'd propose to increase ARCH_NR_GPIOs to 264 in mach/gpio.h or plat/gpio.h instead.

Quoted 3 lines

?#define GPIO_2_x_TO_IRQ(x) ? ? (PXA_GPIO_IRQ_BASE + (x)) ?#define IRQ_GPIO(x) ? ?(((x) < 2) ? (IRQ_GPIO0 + (x)) : GPIO_2_x_TO_IRQ(x))

regards
Philipp

Dmitry Artamonow

2011-12-21 19:19 UTC #2 lore raw

PATCH 1/1 pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

Quoted 12 lines · Philipp Zabel

Hello Paul,
Quoted 9 lines · Paul Parsons
linux-2.6.32 changed the values of PXA_GPIO_IRQ_BASE and PXA_GPIO_IRQ_NUM from 64/128 to 96/192. This has broken the hx4700 platform, for example its PCMCIA/CF driver. The 9 EGPIO GPIOs have become numbered 256..264, and consequently fail the gpio_is_valid() test in gpiolib.c (which limits GPIOs to the range 0..255). This patch reverts the values of PXA_GPIO_IRQ_BASE and PXA_GPIO_IRQ_NUM to their previous linux-2.6.31 values for the hx4700 platform only.
Signed-off-by Paul Parsons <[email protected]>
---

[...]

Quoted 8 lines

Quoted 7 lines
arch/arm/mach-pxa/include/mach/irqs.h +4 -0
+#ifdef CONFIG_MACH_H4700
+#define PXA_GPIO_IRQ_BASE ? ? ?PXA_IRQ(64)
+#define PXA_GPIO_IRQ_NUM ? ? ? (128)
+#else
?#define PXA_GPIO_IRQ_BASE ? ? ?PXA_IRQ(96)
?#define PXA_GPIO_IRQ_NUM ? ? ? (192)
+#endif

Quoted 7 lines

machine specific definitions were removed from mach/irqs.h in commits 0dc726bb264ca5ecfdfab94a6937e0e9b9b26f64 ([ARM] pxa: move board board IRQ definitions out of irqs.h) and 6ac6b817f3f4c23c5febd960d8deb343e13af5f3 (ARM: pxa: encode IRQ number into .nr_irqs).
I'd propose to increase ARCH_NR_GPIOs to 264 in mach/gpio.h or plat/gpio.h instead.

Yes, I also think increasing ARCH_NR_GPIO is the way to go. BTW, there's a patchset floating around which moves such custom settings of ARCH_NR_GPIO from mach/gpio.h into Kconfig variable:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01433.html

I'm not sure though if it's going to be merged into 3.3

Signature · 2 lines

Best regards,
Dmitry "MAD" Artamonow

Haojian Zhuang

maintainer

2011-12-22 05:58 UTC #3 lore raw

PATCH 1/1 pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

Quoted 32 lines · Dmitry Artamonow

Quoted 12 lines · Philipp Zabel
Hello Paul,
Quoted 9 lines · Paul Parsons
linux-2.6.32 changed the values of PXA_GPIO_IRQ_BASE and PXA_GPIO_IRQ_NUM from 64/128 to 96/192. This has broken the hx4700 platform, for example its PCMCIA/CF driver. The 9 EGPIO GPIOs have become numbered 256..264, and consequently fail the gpio_is_valid() test in gpiolib.c (which limits GPIOs to the range 0..255). This patch reverts the values of PXA_GPIO_IRQ_BASE and PXA_GPIO_IRQ_NUM to their previous linux-2.6.31 values for the hx4700 platform only.
Signed-off-by Paul Parsons <[email protected]>
---
[...]
Quoted 8 lines
Quoted 7 lines
arch/arm/mach-pxa/include/mach/irqs.h +4 -0
+#ifdef CONFIG_MACH_H4700
+#define PXA_GPIO_IRQ_BASE ? ? ?PXA_IRQ(64)
+#define PXA_GPIO_IRQ_NUM ? ? ? (128)
+#else
?#define PXA_GPIO_IRQ_BASE ? ? ?PXA_IRQ(96)
?#define PXA_GPIO_IRQ_NUM ? ? ? (192)
+#endif
Quoted 7 lines
machine specific definitions were removed from mach/irqs.h in commits 0dc726bb264ca5ecfdfab94a6937e0e9b9b26f64 ([ARM] pxa: move board board IRQ definitions out of irqs.h) and 6ac6b817f3f4c23c5febd960d8deb343e13af5f3 (ARM: pxa: encode IRQ number into .nr_irqs).
I'd propose to increase ARCH_NR_GPIOs to 264 in mach/gpio.h or plat/gpio.h instead.

Quoted 7 lines

Yes, I also think increasing ARCH_NR_GPIO is the way to go. BTW, there's a patchset floating around which moves such custom settings of ARCH_NR_GPIO from mach/gpio.h into Kconfig variable:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01433.html
I'm not sure though if it's going to be merged into 3.3

I think configuring ARCH_NR_GPIO is not a good solution. Since building one image
is a target. While multiple archs are built together, what will happen?

Maybe we need to change gpio like irq style. User could configure nr_gpio in machine
description.

Thanks
Haojian

Dmitry Artamonow

2011-12-22 19:49 UTC #4 lore raw

PATCH 1/1 pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

Quoted 7 lines · Haojian Zhuang

Quoted 6 lines · Dmitry Artamonow
Yes, I also think increasing ARCH_NR_GPIO is the way to go. BTW, there's a patchset floating around which moves such custom settings of ARCH_NR_GPIO from mach/gpio.h into Kconfig variable:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01433.html

Quoted 5 lines

Quoted 2 lines
I'm not sure though if it's going to be merged into 3.3
I think configuring ARCH_NR_GPIO is not a good solution. Since building one image
is a target. While multiple archs are built together, what will happen?

Setting custom ARCH_NR_GPIO in mach/gpio.h does scale only inside one sub-arch, but the patch from the set above which migrates ARCH_NR_GPIO to arch/arm/include/asm/gpio.h and converts it into Kconfig variable should help to select proper ARCH_NR_GPIO even for multi-arch kernels (Kconfig's magic will ensure that proper maximal value of ARCH_NR_GPIO is selected for each combination of platforms)

See the patch here:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01431.html

and Russell's explanation of Kconfig magic here:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01577.html

Quoted 4 lines

Maybe we need to change gpio like irq style. User could configure nr_gpio in machine
description.

That's probably a good idea - I personally don't see much sense in having some randomly chosen arbitrarily big ARCH_NR_GPIO anyway, so it would be nice to have more advanced mechanisms in place of this. But I'm not sure if keeping hx4700 broken until some good infrastructure will come up is a good idea.

Signature · 2 lines

Best regards,
Dmitry "MAD" Artamonow

Haojian Zhuang

maintainer

2012-01-04 06:41 UTC #5 lore raw

PATCH 1/1 pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

Quoted 21 lines · Dmitry Artamonow

Quoted 7 lines · Haojian Zhuang
Quoted 6 lines · Dmitry Artamonow
Yes, I also think increasing ARCH_NR_GPIO is the way to go. BTW, there's a patchset floating around which moves such custom settings of ARCH_NR_GPIO from mach/gpio.h into Kconfig variable:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01433.html
Quoted 5 lines
Quoted 2 lines
I'm not sure though if it's going to be merged into 3.3
I think configuring ARCH_NR_GPIO is not a good solution. Since building one image
is a target. While multiple archs are built together, what will happen?
Setting custom ARCH_NR_GPIO in mach/gpio.h does scale only inside one sub-arch, but the patch from the set above which migrates ARCH_NR_GPIO to arch/arm/include/asm/gpio.h and converts it into Kconfig variable should help to select proper ARCH_NR_GPIO even for multi-arch kernels (Kconfig's magic will ensure that proper maximal value of ARCH_NR_GPIO is selected for each combination of platforms)

Quoted 6 lines

See the patch here:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01431.html
and Russell's explanation of Kconfig magic here:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01577.html

Excuse me to response so late.

Russell,

Since I failed to access your git tree, I can't verity whether the ARCH_NR_GPIO patch set is merged into your tree. Could you help to confirm this?

Best Regards
Haojian

Russell King - ARM Linux

2012-01-04 09:17 UTC #6 lore raw

PATCH 1/1 pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

Quoted 29 lines · Haojian Zhuang

Quoted 21 lines · Dmitry Artamonow
Quoted 7 lines · Haojian Zhuang
Quoted 6 lines · Dmitry Artamonow
Yes, I also think increasing ARCH_NR_GPIO is the way to go. BTW, there's a patchset floating around which moves such custom settings of ARCH_NR_GPIO from mach/gpio.h into Kconfig variable:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01433.html
Quoted 5 lines
Quoted 2 lines
I'm not sure though if it's going to be merged into 3.3
I think configuring ARCH_NR_GPIO is not a good solution. Since building one image
is a target. While multiple archs are built together, what will happen?
Setting custom ARCH_NR_GPIO in mach/gpio.h does scale only inside one sub-arch, but the patch from the set above which migrates ARCH_NR_GPIO to arch/arm/include/asm/gpio.h and converts it into Kconfig variable should help to select proper ARCH_NR_GPIO even for multi-arch kernels (Kconfig's magic will ensure that proper maximal value of ARCH_NR_GPIO is selected for each combination of platforms)
Quoted 6 lines
See the patch here:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01431.html
and Russell's explanation of Kconfig magic here:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01577.html

Quoted 6 lines

Excuse me to response so late.
Russell,
Since I failed to access your git tree, I can't verity whether the ARCH_NR_GPIO patch set is merged into your tree. Could you help to confirm this?

commit 44986ab056076e9dc9fb9f8b4729afef7fa72616

Author: Peter De Schrijver (NVIDIA) <[email protected]>
Date:   Wed Dec 21 10:48:45 2011 +0100

ARM: 7240/1: Make ARCH_NR_GPIO a Kconfig variable

Change ARCH_NR_GPIO into a Kconfig variable as suggested by Russel King. This makes ARCH_NR_GPIO single zImage friendly. The default value for tegra is defined as well.

Signed-off-by Peter De Schrijver <[email protected]>

Signed-off-by Russell King <[email protected]>

Haojian Zhuang

maintainer

2012-01-05 00:21 UTC #7 lore raw

PATCH 1/1 pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

Quoted 41 lines · Russell King - ARM Linux

Quoted 29 lines · Haojian Zhuang
Quoted 21 lines · Dmitry Artamonow
Quoted 7 lines · Haojian Zhuang
Quoted 6 lines · Dmitry Artamonow
Yes, I also think increasing ARCH_NR_GPIO is the way to go. BTW, there's a patchset floating around which moves such custom settings of ARCH_NR_GPIO from mach/gpio.h into Kconfig variable:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01433.html
Quoted 5 lines
Quoted 2 lines
I'm not sure though if it's going to be merged into 3.3
I think configuring ARCH_NR_GPIO is not a good solution. Since building one image
is a target. While multiple archs are built together, what will happen?
Setting custom ARCH_NR_GPIO in mach/gpio.h does scale only inside one sub-arch, but the patch from the set above which migrates ARCH_NR_GPIO to arch/arm/include/asm/gpio.h and converts it into Kconfig variable should help to select proper ARCH_NR_GPIO even for multi-arch kernels (Kconfig's magic will ensure that proper maximal value of ARCH_NR_GPIO is selected for each combination of platforms)
Quoted 6 lines
See the patch here:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01431.html
and Russell's explanation of Kconfig magic here:
http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01577.html
Quoted 6 lines
Excuse me to response so late.
Russell,
Since I failed to access your git tree, I can't verity whether the ARCH_NR_GPIO patch set is merged into your tree. Could you help to confirm this?
commit 44986ab056076e9dc9fb9f8b4729afef7fa72616
Author: Peter De Schrijver (NVIDIA) <[email protected]>
Date: ? Wed Dec 21 10:48:45 2011 +0100

Quoted 9 lines

? ?ARM: 7240/1: Make ARCH_NR_GPIO a Kconfig variable
? ?Change ARCH_NR_GPIO into a Kconfig variable as suggested by Russel King. ? ?This makes ARCH_NR_GPIO single zImage friendly. The default value for ? ?tegra is defined as well.
? ?Signed-off-by: Peter De Schrijver <[email protected]> ? ?Signed-off-by: Russell King <[email protected]>

Thanks a lot, Russell

Philipp,

Could you help to change your patch based on this as Dmitry suggested?

Best Regards
Haojian