[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[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 <lost.distance@yahoo.com>
---

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
--- clean-3.2-rc5/arch/arm/mach-pxa/include/mach/irqs.h	2011-12-09 23:09:32.000000000 +0000
+++ linux-3.2-rc5/arch/arm/mach-pxa/include/mach/irqs.h	2011-12-12 15:21:09.770483920 +0000
@@ -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))

[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[Philipp Zabel]

Hello Paul,

On Mon, Dec 12, 2011 at 11:21 PM, Paul Parsons <lost.distance@yahoo.com> wrote:
> 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 <lost.distance@yahoo.com>
> ---
>
> 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
> --- clean-3.2-rc5/arch/arm/mach-pxa/include/mach/irqs.h 2011-12-09 23:09:32.000000000 +0000
> +++ linux-3.2-rc5/arch/arm/mach-pxa/include/mach/irqs.h 2011-12-12 15:21:09.770483920 +0000
> @@ -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

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.

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

[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[Dmitry Artamonow]

On 15:12 Wed 21 Dec     , Philipp Zabel wrote:
> Hello Paul,
> 
> On Mon, Dec 12, 2011 at 11:21 PM, Paul Parsons <lost.distance@yahoo.com> wrote:
> > 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 <lost.distance@yahoo.com>
> > ---

[...]

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

-- 
Best regards,
Dmitry "MAD" Artamonow

[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[Haojian Zhuang]

On Thu, Dec 22, 2011 at 3:19 AM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
> On 15:12 Wed 21 Dec ? ? , Philipp Zabel wrote:
>> Hello Paul,
>>
>> On Mon, Dec 12, 2011 at 11:21 PM, Paul Parsons <lost.distance@yahoo.com> wrote:
>> > 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 <lost.distance@yahoo.com>
>> > ---
>
> [...]
>
>> > +#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
>>
>> 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
>
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

[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[Dmitry Artamonow]

On 13:58 Thu 22 Dec     , Haojian Zhuang wrote:
> On Thu, Dec 22, 2011 at 3:19 AM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
> >
> > 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?

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

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

-- 
Best regards,
Dmitry "MAD" Artamonow

[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[Haojian Zhuang]

On Fri, Dec 23, 2011 at 3:49 AM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
> On 13:58 Thu 22 Dec ? ? , Haojian Zhuang wrote:
>> On Thu, Dec 22, 2011 at 3:19 AM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
>> >
>> > 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?
>
> 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
>

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

[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[Russell King - ARM Linux]

On Wed, Jan 04, 2012 at 02:41:47PM +0800, Haojian Zhuang wrote:
> On Fri, Dec 23, 2011 at 3:49 AM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
> > On 13:58 Thu 22 Dec ? ? , Haojian Zhuang wrote:
> >> On Thu, Dec 22, 2011 at 3:19 AM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
> >> >
> >> > 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?
> >
> > 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
> >
> 
> 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) <pdeschrijver@nvidia.com>
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 <pdeschrijver@nvidia.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

?

[PATCH] pxa/hx4700: Fix PXA_GPIO_IRQ_BASE/IRQ_NUM values

[Haojian Zhuang]

On Wed, Jan 4, 2012 at 5:17 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 04, 2012 at 02:41:47PM +0800, Haojian Zhuang wrote:
>> On Fri, Dec 23, 2011 at 3:49 AM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
>> > On 13:58 Thu 22 Dec ? ? , Haojian Zhuang wrote:
>> >> On Thu, Dec 22, 2011 at 3:19 AM, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
>> >> >
>> >> > 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?
>> >
>> > 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
>> >
>>
>> 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) <pdeschrijver@nvidia.com>
> 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 <pdeschrijver@nvidia.com>
> ? ?Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
Thanks a lot, Russell

Philipp,

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

Best Regards
Haojian