[PATCH 0/4] ARM IRQ Changes

[PATCH 0/4] ARM IRQ Changes

[Felipe Balbi]

Hi all,

a few patches to enable sparse IRQ numbering on OMAP.
Also a few cleanups to arch/arm/Kconfig.

for convenience patches are also available from [1]:

[1] git://gitorious.org/usb/usb.git irq

Felipe Balbi (4):
  arm: omap: gpio: don't access irq_desc array directly
  arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
  arm: Kconfig: remove duplicated SPARSE_IRQ entry
  arm: Kconfig: allow OMAP to use sparse IRQ numbering

 arch/arm/Kconfig          |   22 ++++------------------
 arch/arm/plat-omap/gpio.c |   10 +++++++---
 2 files changed, 11 insertions(+), 21 deletions(-)

-- 
1.7.3.4.598.g85356

[PATCH 0/4] ARM IRQ Changes

[Felipe Balbi]

Hi all,

a few patches to enable sparse IRQ numbering on OMAP.
Also a few cleanups to arch/arm/Kconfig.

for convenience patches are also available from [1]:

[1] git://gitorious.org/usb/usb.git irq

Felipe Balbi (4):
  arm: omap: gpio: don't access irq_desc array directly
  arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
  arm: Kconfig: remove duplicated SPARSE_IRQ entry
  arm: Kconfig: allow OMAP to use sparse IRQ numbering

 arch/arm/Kconfig          |   22 ++++------------------
 arch/arm/plat-omap/gpio.c |   10 +++++++---
 2 files changed, 11 insertions(+), 21 deletions(-)

-- 
1.7.3.4.598.g85356

[PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly

[Felipe Balbi]

Instead of accessing the irq_desc array directly
we can use irq_to_desc(irq). That will allow us to,
if wanted, select SPARSE_IRQ and irq_descs will be
added to a radix tree, instead of a array.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/plat-omap/gpio.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index c05c653..c351758 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -905,8 +905,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
 	spin_lock_irqsave(&bank->lock, flags);
 	retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
 	if (retval == 0) {
-		irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
-		irq_desc[irq].status |= type;
+		struct irq_desc *d = irq_to_desc(irq);
+
+		d->status &= ~IRQ_TYPE_SENSE_MASK;
+		d->status |= type;
 	}
 	spin_unlock_irqrestore(&bank->lock, flags);
 
@@ -1925,7 +1927,9 @@ static int __init _omap_gpio_init(void)
 
 		for (j = bank->virtual_irq_start;
 		     j < bank->virtual_irq_start + gpio_count; j++) {
-			lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
+			struct irq_desc *d = irq_to_desc(j);
+
+			lockdep_set_class(&d->lock, &gpio_lock_class);
 			set_irq_chip_data(j, bank);
 			if (bank_is_mpuio(bank))
 				set_irq_chip(j, &mpuio_irq_chip);
-- 
1.7.3.4.598.g85356

[PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly

[Felipe Balbi]

Instead of accessing the irq_desc array directly
we can use irq_to_desc(irq). That will allow us to,
if wanted, select SPARSE_IRQ and irq_descs will be
added to a radix tree, instead of a array.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/plat-omap/gpio.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index c05c653..c351758 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -905,8 +905,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
 	spin_lock_irqsave(&bank->lock, flags);
 	retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
 	if (retval == 0) {
-		irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
-		irq_desc[irq].status |= type;
+		struct irq_desc *d = irq_to_desc(irq);
+
+		d->status &= ~IRQ_TYPE_SENSE_MASK;
+		d->status |= type;
 	}
 	spin_unlock_irqrestore(&bank->lock, flags);
 
@@ -1925,7 +1927,9 @@ static int __init _omap_gpio_init(void)
 
 		for (j = bank->virtual_irq_start;
 		     j < bank->virtual_irq_start + gpio_count; j++) {
-			lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
+			struct irq_desc *d = irq_to_desc(j);
+
+			lockdep_set_class(&d->lock, &gpio_lock_class);
 			set_irq_chip_data(j, bank);
 			if (bank_is_mpuio(bank))
 				set_irq_chip(j, &mpuio_irq_chip);
-- 
1.7.3.4.598.g85356

Re: [PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly

[Kevin Hilman]

Felipe Balbi <balbi@ti.com> writes:

> Instead of accessing the irq_desc array directly
> we can use irq_to_desc(irq). That will allow us to,
> if wanted, select SPARSE_IRQ and irq_descs will be
> added to a radix tree, instead of a array.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>

Can you refresh this one against Tony's omap-for-linus branch. The GPIO
omap_device/hwmod conversion changed things around a bit and this patch
doesn't apply.

After that, you can send separately, and I'll queue this one along with
some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
out.

Kevin

> ---
>  arch/arm/plat-omap/gpio.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index c05c653..c351758 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -905,8 +905,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
>  	spin_lock_irqsave(&bank->lock, flags);
>  	retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
>  	if (retval == 0) {
> -		irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
> -		irq_desc[irq].status |= type;
> +		struct irq_desc *d = irq_to_desc(irq);
> +
> +		d->status &= ~IRQ_TYPE_SENSE_MASK;
> +		d->status |= type;
>  	}
>  	spin_unlock_irqrestore(&bank->lock, flags);
>  
> @@ -1925,7 +1927,9 @@ static int __init _omap_gpio_init(void)
>  
>  		for (j = bank->virtual_irq_start;
>  		     j < bank->virtual_irq_start + gpio_count; j++) {
> -			lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
> +			struct irq_desc *d = irq_to_desc(j);
> +
> +			lockdep_set_class(&d->lock, &gpio_lock_class);
>  			set_irq_chip_data(j, bank);
>  			if (bank_is_mpuio(bank))
>  				set_irq_chip(j, &mpuio_irq_chip);

[PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly

[Kevin Hilman]

Felipe Balbi <balbi@ti.com> writes:

> Instead of accessing the irq_desc array directly
> we can use irq_to_desc(irq). That will allow us to,
> if wanted, select SPARSE_IRQ and irq_descs will be
> added to a radix tree, instead of a array.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>

Can you refresh this one against Tony's omap-for-linus branch. The GPIO
omap_device/hwmod conversion changed things around a bit and this patch
doesn't apply.

After that, you can send separately, and I'll queue this one along with
some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
out.

Kevin

> ---
>  arch/arm/plat-omap/gpio.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index c05c653..c351758 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -905,8 +905,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
>  	spin_lock_irqsave(&bank->lock, flags);
>  	retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
>  	if (retval == 0) {
> -		irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
> -		irq_desc[irq].status |= type;
> +		struct irq_desc *d = irq_to_desc(irq);
> +
> +		d->status &= ~IRQ_TYPE_SENSE_MASK;
> +		d->status |= type;
>  	}
>  	spin_unlock_irqrestore(&bank->lock, flags);
>  
> @@ -1925,7 +1927,9 @@ static int __init _omap_gpio_init(void)
>  
>  		for (j = bank->virtual_irq_start;
>  		     j < bank->virtual_irq_start + gpio_count; j++) {
> -			lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
> +			struct irq_desc *d = irq_to_desc(j);
> +
> +			lockdep_set_class(&d->lock, &gpio_lock_class);
>  			set_irq_chip_data(j, bank);
>  			if (bank_is_mpuio(bank))
>  				set_irq_chip(j, &mpuio_irq_chip);

Re: [PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Tue, Jan 04, 2011 at 04:24:58PM -0800, Kevin Hilman wrote:
> Felipe Balbi <balbi@ti.com> writes:
> 
> > Instead of accessing the irq_desc array directly
> > we can use irq_to_desc(irq). That will allow us to,
> > if wanted, select SPARSE_IRQ and irq_descs will be
> > added to a radix tree, instead of a array.
> >
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> 
> Can you refresh this one against Tony's omap-for-linus branch. The GPIO
> omap_device/hwmod conversion changed things around a bit and this patch
> doesn't apply.
> 
> After that, you can send separately, and I'll queue this one along with
> some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
> out.

Sure, it's attached to this mail.

-- 
balbi

[-- Attachment #2: 0001-arm-omap-gpio-don-t-access-irq_desc-array-directly.diff --]
[-- Type: text/x-diff, Size: 1643 bytes --]

>From 8d216ccac14e4eebf259d5b40ed2d239248710e1 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Wed, 5 Jan 2011 08:46:18 +0200
Subject: [PATCH] arm: omap: gpio: don't access irq_desc array directly
Organization: Texas Instruments\n

Instead of accessing the irq_desc array directly
we can use irq_to_desc(irq). That will allow us to,
if wanted, select SPARSE_IRQ and irq_descs will be
added to a radix tree, instead of a array.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/plat-omap/gpio.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 1f98e0b..197a6c0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -756,8 +756,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
 	spin_lock_irqsave(&bank->lock, flags);
 	retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
 	if (retval == 0) {
-		irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
-		irq_desc[irq].status |= type;
+		struct irq_desc *d = irq_to_desc(irq);
+
+		d->status &= ~IRQ_TYPE_SENSE_MASK;
+		d->status |= type;
 	}
 	spin_unlock_irqrestore(&bank->lock, flags);
 
@@ -1671,7 +1673,9 @@ static void __init omap_gpio_chip_init(struct gpio_bank *bank)
 
 	for (j = bank->virtual_irq_start;
 		     j < bank->virtual_irq_start + bank_width; j++) {
-		lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
+		struct irq_desc *d = irq_to_desc(j);
+
+		lockdep_set_class(&d->lock, &gpio_lock_class);
 		set_irq_chip_data(j, bank);
 		if (bank_is_mpuio(bank))
 			set_irq_chip(j, &mpuio_irq_chip);
-- 
1.7.3.4.598.g85356

[PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly

[Felipe Balbi]

On Tue, Jan 04, 2011 at 04:24:58PM -0800, Kevin Hilman wrote:
> Felipe Balbi <balbi@ti.com> writes:
> 
> > Instead of accessing the irq_desc array directly
> > we can use irq_to_desc(irq). That will allow us to,
> > if wanted, select SPARSE_IRQ and irq_descs will be
> > added to a radix tree, instead of a array.
> >
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> 
> Can you refresh this one against Tony's omap-for-linus branch. The GPIO
> omap_device/hwmod conversion changed things around a bit and this patch
> doesn't apply.
> 
> After that, you can send separately, and I'll queue this one along with
> some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
> out.

Sure, it's attached to this mail.

-- 
balbi

Re: [PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly

[Kevin Hilman]

Felipe Balbi <balbi@ti.com> writes:

> On Tue, Jan 04, 2011 at 04:24:58PM -0800, Kevin Hilman wrote:
>> Felipe Balbi <balbi@ti.com> writes:
>> 
>> > Instead of accessing the irq_desc array directly
>> > we can use irq_to_desc(irq). That will allow us to,
>> > if wanted, select SPARSE_IRQ and irq_descs will be
>> > added to a radix tree, instead of a array.
>> >
>> > Signed-off-by: Felipe Balbi <balbi@ti.com>
>> 
>> Can you refresh this one against Tony's omap-for-linus branch. The GPIO
>> omap_device/hwmod conversion changed things around a bit and this patch
>> doesn't apply.
>> 
>> After that, you can send separately, and I'll queue this one along with
>> some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
>> out.
>
> Sure, it's attached to this mail.

Thanks.  Queueing for 2.6.38-rc

Kevin

>
> From 8d216ccac14e4eebf259d5b40ed2d239248710e1 Mon Sep 17 00:00:00 2001
> From: Felipe Balbi <balbi@ti.com>
> Date: Wed, 5 Jan 2011 08:46:18 +0200
> Subject: [PATCH] arm: omap: gpio: don't access irq_desc array directly
> Organization: Texas Instruments\n
>
> Instead of accessing the irq_desc array directly
> we can use irq_to_desc(irq). That will allow us to,
> if wanted, select SPARSE_IRQ and irq_descs will be
> added to a radix tree, instead of a array.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  arch/arm/plat-omap/gpio.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 1f98e0b..197a6c0 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -756,8 +756,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
>  	spin_lock_irqsave(&bank->lock, flags);
>  	retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
>  	if (retval == 0) {
> -		irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
> -		irq_desc[irq].status |= type;
> +		struct irq_desc *d = irq_to_desc(irq);
> +
> +		d->status &= ~IRQ_TYPE_SENSE_MASK;
> +		d->status |= type;
>  	}
>  	spin_unlock_irqrestore(&bank->lock, flags);
>  
> @@ -1671,7 +1673,9 @@ static void __init omap_gpio_chip_init(struct gpio_bank *bank)
>  
>  	for (j = bank->virtual_irq_start;
>  		     j < bank->virtual_irq_start + bank_width; j++) {
> -		lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
> +		struct irq_desc *d = irq_to_desc(j);
> +
> +		lockdep_set_class(&d->lock, &gpio_lock_class);
>  		set_irq_chip_data(j, bank);
>  		if (bank_is_mpuio(bank))
>  			set_irq_chip(j, &mpuio_irq_chip);

[PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly

[Kevin Hilman]

Felipe Balbi <balbi@ti.com> writes:

> On Tue, Jan 04, 2011 at 04:24:58PM -0800, Kevin Hilman wrote:
>> Felipe Balbi <balbi@ti.com> writes:
>> 
>> > Instead of accessing the irq_desc array directly
>> > we can use irq_to_desc(irq). That will allow us to,
>> > if wanted, select SPARSE_IRQ and irq_descs will be
>> > added to a radix tree, instead of a array.
>> >
>> > Signed-off-by: Felipe Balbi <balbi@ti.com>
>> 
>> Can you refresh this one against Tony's omap-for-linus branch. The GPIO
>> omap_device/hwmod conversion changed things around a bit and this patch
>> doesn't apply.
>> 
>> After that, you can send separately, and I'll queue this one along with
>> some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
>> out.
>
> Sure, it's attached to this mail.

Thanks.  Queueing for 2.6.38-rc

Kevin

>
> From 8d216ccac14e4eebf259d5b40ed2d239248710e1 Mon Sep 17 00:00:00 2001
> From: Felipe Balbi <balbi@ti.com>
> Date: Wed, 5 Jan 2011 08:46:18 +0200
> Subject: [PATCH] arm: omap: gpio: don't access irq_desc array directly
> Organization: Texas Instruments\n
>
> Instead of accessing the irq_desc array directly
> we can use irq_to_desc(irq). That will allow us to,
> if wanted, select SPARSE_IRQ and irq_descs will be
> added to a radix tree, instead of a array.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  arch/arm/plat-omap/gpio.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 1f98e0b..197a6c0 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -756,8 +756,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
>  	spin_lock_irqsave(&bank->lock, flags);
>  	retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
>  	if (retval == 0) {
> -		irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
> -		irq_desc[irq].status |= type;
> +		struct irq_desc *d = irq_to_desc(irq);
> +
> +		d->status &= ~IRQ_TYPE_SENSE_MASK;
> +		d->status |= type;
>  	}
>  	spin_unlock_irqrestore(&bank->lock, flags);
>  
> @@ -1671,7 +1673,9 @@ static void __init omap_gpio_chip_init(struct gpio_bank *bank)
>  
>  	for (j = bank->virtual_irq_start;
>  		     j < bank->virtual_irq_start + bank_width; j++) {
> -		lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
> +		struct irq_desc *d = irq_to_desc(j);
> +
> +		lockdep_set_class(&d->lock, &gpio_lock_class);
>  		set_irq_chip_data(j, bank);
>  		if (bank_is_mpuio(bank))
>  			set_irq_chip(j, &mpuio_irq_chip);

[PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Felipe Balbi]

GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
so it's safe to drop the duplicated entry and simply
select HAVE_GENERIC_HARDIRQS.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/Kconfig |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d56d21c0..e6f0f8b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -15,6 +15,7 @@ config ARM
 	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
 	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
 	select HAVE_GENERIC_DMA_COHERENT
+	select HAVE_GENERIC_HARDIRQS
 	select HAVE_KERNEL_GZIP
 	select HAVE_KERNEL_LZO
 	select HAVE_KERNEL_LZMA
@@ -88,10 +89,6 @@ config MCA
 	  <file:Documentation/mca.txt> (and especially the web page given
 	  there) before attempting to build an MCA bus kernel.
 
-config GENERIC_HARDIRQS
-	bool
-	default y
-
 config STACKTRACE_SUPPORT
 	bool
 	default y
@@ -171,9 +168,6 @@ config FIQ
 config ARCH_MTD_XIP
 	bool
 
-config GENERIC_HARDIRQS_NO__DO_IRQ
-	def_bool y
-
 config ARM_L1_CACHE_SHIFT_6
 	bool
 	help
-- 
1.7.3.4.598.g85356

[PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Felipe Balbi]

GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
so it's safe to drop the duplicated entry and simply
select HAVE_GENERIC_HARDIRQS.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/Kconfig |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d56d21c0..e6f0f8b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -15,6 +15,7 @@ config ARM
 	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
 	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
 	select HAVE_GENERIC_DMA_COHERENT
+	select HAVE_GENERIC_HARDIRQS
 	select HAVE_KERNEL_GZIP
 	select HAVE_KERNEL_LZO
 	select HAVE_KERNEL_LZMA
@@ -88,10 +89,6 @@ config MCA
 	  <file:Documentation/mca.txt> (and especially the web page given
 	  there) before attempting to build an MCA bus kernel.
 
-config GENERIC_HARDIRQS
-	bool
-	default y
-
 config STACKTRACE_SUPPORT
 	bool
 	default y
@@ -171,9 +168,6 @@ config FIQ
 config ARCH_MTD_XIP
 	bool
 
-config GENERIC_HARDIRQS_NO__DO_IRQ
-	def_bool y
-
 config ARM_L1_CACHE_SHIFT_6
 	bool
 	help
-- 
1.7.3.4.598.g85356

Re: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Uwe Kleine-König]

On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
> so it's safe to drop the duplicated entry and simply
> select HAVE_GENERIC_HARDIRQS.
> 
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  arch/arm/Kconfig |    8 +-------
>  1 files changed, 1 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d56d21c0..e6f0f8b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -15,6 +15,7 @@ config ARM
>  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
>  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
>  	select HAVE_GENERIC_DMA_COHERENT
> +	select HAVE_GENERIC_HARDIRQS
>  	select HAVE_KERNEL_GZIP
>  	select HAVE_KERNEL_LZO
>  	select HAVE_KERNEL_LZMA
> @@ -88,10 +89,6 @@ config MCA
>  	  <file:Documentation/mca.txt> (and especially the web page given
>  	  there) before attempting to build an MCA bus kernel.
>  
> -config GENERIC_HARDIRQS
> -	bool
> -	default y
> -
>  config STACKTRACE_SUPPORT
>  	bool
>  	default y
> @@ -171,9 +168,6 @@ config FIQ
>  config ARCH_MTD_XIP
>  	bool
>  
> -config GENERIC_HARDIRQS_NO__DO_IRQ
> -	def_bool y
> -
You didn't mention this change in the commit log.  Is this duplicated,
too or did it just slip through?

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Uwe Kleine-König]

On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
> so it's safe to drop the duplicated entry and simply
> select HAVE_GENERIC_HARDIRQS.
> 
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  arch/arm/Kconfig |    8 +-------
>  1 files changed, 1 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d56d21c0..e6f0f8b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -15,6 +15,7 @@ config ARM
>  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
>  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
>  	select HAVE_GENERIC_DMA_COHERENT
> +	select HAVE_GENERIC_HARDIRQS
>  	select HAVE_KERNEL_GZIP
>  	select HAVE_KERNEL_LZO
>  	select HAVE_KERNEL_LZMA
> @@ -88,10 +89,6 @@ config MCA
>  	  <file:Documentation/mca.txt> (and especially the web page given
>  	  there) before attempting to build an MCA bus kernel.
>  
> -config GENERIC_HARDIRQS
> -	bool
> -	default y
> -
>  config STACKTRACE_SUPPORT
>  	bool
>  	default y
> @@ -171,9 +168,6 @@ config FIQ
>  config ARCH_MTD_XIP
>  	bool
>  
> -config GENERIC_HARDIRQS_NO__DO_IRQ
> -	def_bool y
> -
You didn't mention this change in the commit log.  Is this duplicated,
too or did it just slip through?

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Felipe Balbi]

On Tue, 2011-01-04 at 15:00 +0100, Uwe Kleine-König wrote:
> On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> > GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
> > so it's safe to drop the duplicated entry and simply
> > select HAVE_GENERIC_HARDIRQS.
> > 
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >  arch/arm/Kconfig |    8 +-------
> >  1 files changed, 1 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index d56d21c0..e6f0f8b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -15,6 +15,7 @@ config ARM
> >  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> >  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> >  	select HAVE_GENERIC_DMA_COHERENT
> > +	select HAVE_GENERIC_HARDIRQS
> >  	select HAVE_KERNEL_GZIP
> >  	select HAVE_KERNEL_LZO
> >  	select HAVE_KERNEL_LZMA
> > @@ -88,10 +89,6 @@ config MCA
> >  	  <file:Documentation/mca.txt> (and especially the web page given
> >  	  there) before attempting to build an MCA bus kernel.
> >  
> > -config GENERIC_HARDIRQS
> > -	bool
> > -	default y
> > -
> >  config STACKTRACE_SUPPORT
> >  	bool
> >  	default y
> > @@ -171,9 +168,6 @@ config FIQ
> >  config ARCH_MTD_XIP
> >  	bool
> >  
> > -config GENERIC_HARDIRQS_NO__DO_IRQ
> > -	def_bool y
> > -
> You didn't mention this change in the commit log.  Is this duplicated,
> too or did it just slip through?

Yes it is. My bad. Do I need to update the patch ? I can do it tomorrow.

-- 
balbi

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Felipe Balbi]

On Tue, 2011-01-04 at 15:00 +0100, Uwe Kleine-K?nig wrote:
> On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> > GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
> > so it's safe to drop the duplicated entry and simply
> > select HAVE_GENERIC_HARDIRQS.
> > 
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >  arch/arm/Kconfig |    8 +-------
> >  1 files changed, 1 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index d56d21c0..e6f0f8b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -15,6 +15,7 @@ config ARM
> >  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> >  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> >  	select HAVE_GENERIC_DMA_COHERENT
> > +	select HAVE_GENERIC_HARDIRQS
> >  	select HAVE_KERNEL_GZIP
> >  	select HAVE_KERNEL_LZO
> >  	select HAVE_KERNEL_LZMA
> > @@ -88,10 +89,6 @@ config MCA
> >  	  <file:Documentation/mca.txt> (and especially the web page given
> >  	  there) before attempting to build an MCA bus kernel.
> >  
> > -config GENERIC_HARDIRQS
> > -	bool
> > -	default y
> > -
> >  config STACKTRACE_SUPPORT
> >  	bool
> >  	default y
> > @@ -171,9 +168,6 @@ config FIQ
> >  config ARCH_MTD_XIP
> >  	bool
> >  
> > -config GENERIC_HARDIRQS_NO__DO_IRQ
> > -	def_bool y
> > -
> You didn't mention this change in the commit log.  Is this duplicated,
> too or did it just slip through?

Yes it is. My bad. Do I need to update the patch ? I can do it tomorrow.

-- 
balbi

Re: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Russell King - ARM Linux]

On Tue, Jan 04, 2011 at 03:00:31PM +0100, Uwe Kleine-König wrote:
> On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> > GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
> > so it's safe to drop the duplicated entry and simply
> > select HAVE_GENERIC_HARDIRQS.
> > 
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >  arch/arm/Kconfig |    8 +-------
> >  1 files changed, 1 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index d56d21c0..e6f0f8b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -15,6 +15,7 @@ config ARM
> >  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> >  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> >  	select HAVE_GENERIC_DMA_COHERENT
> > +	select HAVE_GENERIC_HARDIRQS
> >  	select HAVE_KERNEL_GZIP
> >  	select HAVE_KERNEL_LZO
> >  	select HAVE_KERNEL_LZMA
> > @@ -88,10 +89,6 @@ config MCA
> >  	  <file:Documentation/mca.txt> (and especially the web page given
> >  	  there) before attempting to build an MCA bus kernel.
> >  
> > -config GENERIC_HARDIRQS
> > -	bool
> > -	default y
> > -
> >  config STACKTRACE_SUPPORT
> >  	bool
> >  	default y
> > @@ -171,9 +168,6 @@ config FIQ
> >  config ARCH_MTD_XIP
> >  	bool
> >  
> > -config GENERIC_HARDIRQS_NO__DO_IRQ
> > -	def_bool y
> > -
> You didn't mention this change in the commit log.  Is this duplicated,
> too or did it just slip through?

If you look at kernel/irq/Kconfig (as I did with the original patch)
you'd notice kernel/irq/Kconfig defines both of these symbols being
removed when HAVE_GENERIC_HARDIRQS is enabled.

If you read the discussion in the previous version of this patch set,
you'd notice that the removal of this was specifically requested.

It's very tiresome to have to re-explain these things.  Please take
some more time to research the points you bring up, rather than
impulse-replying.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Russell King - ARM Linux]

On Tue, Jan 04, 2011 at 03:00:31PM +0100, Uwe Kleine-K?nig wrote:
> On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> > GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
> > so it's safe to drop the duplicated entry and simply
> > select HAVE_GENERIC_HARDIRQS.
> > 
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >  arch/arm/Kconfig |    8 +-------
> >  1 files changed, 1 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index d56d21c0..e6f0f8b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -15,6 +15,7 @@ config ARM
> >  	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> >  	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
> >  	select HAVE_GENERIC_DMA_COHERENT
> > +	select HAVE_GENERIC_HARDIRQS
> >  	select HAVE_KERNEL_GZIP
> >  	select HAVE_KERNEL_LZO
> >  	select HAVE_KERNEL_LZMA
> > @@ -88,10 +89,6 @@ config MCA
> >  	  <file:Documentation/mca.txt> (and especially the web page given
> >  	  there) before attempting to build an MCA bus kernel.
> >  
> > -config GENERIC_HARDIRQS
> > -	bool
> > -	default y
> > -
> >  config STACKTRACE_SUPPORT
> >  	bool
> >  	default y
> > @@ -171,9 +168,6 @@ config FIQ
> >  config ARCH_MTD_XIP
> >  	bool
> >  
> > -config GENERIC_HARDIRQS_NO__DO_IRQ
> > -	def_bool y
> > -
> You didn't mention this change in the commit log.  Is this duplicated,
> too or did it just slip through?

If you look at kernel/irq/Kconfig (as I did with the original patch)
you'd notice kernel/irq/Kconfig defines both of these symbols being
removed when HAVE_GENERIC_HARDIRQS is enabled.

If you read the discussion in the previous version of this patch set,
you'd notice that the removal of this was specifically requested.

It's very tiresome to have to re-explain these things.  Please take
some more time to research the points you bring up, rather than
impulse-replying.

Re: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Uwe Kleine-König]

Hi Russell,

On Tue, Jan 04, 2011 at 05:33:01PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 04, 2011 at 03:00:31PM +0100, Uwe Kleine-König wrote:
> > On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> > > @@ -171,9 +168,6 @@ config FIQ
> > >  config ARCH_MTD_XIP
> > >  	bool
> > >  
> > > -config GENERIC_HARDIRQS_NO__DO_IRQ
> > > -	def_bool y
> > > -
> > You didn't mention this change in the commit log.  Is this duplicated,
> > too or did it just slip through?
> 
> If you look at kernel/irq/Kconfig (as I did with the original patch)
> you'd notice kernel/irq/Kconfig defines both of these symbols being
> removed when HAVE_GENERIC_HARDIRQS is enabled.
> 
> If you read the discussion in the previous version of this patch set,
> you'd notice that the removal of this was specifically requested.
> 
> It's very tiresome to have to re-explain these things.  Please take
> some more time to research the points you bring up, rather than
I don't agree here 100%.  IMHO the commit log was not good enough for
the change introduced by the patch (and Felipe's reply suggests that he
agrees).  I could still research it, but:

 - it was not obvious for me there was a previous version (no "v2" or
   similar in the patch subject);
 - for me it would take say 5 minutes to check, the author knows
   the answer to my question immediately (at least he should);
 - after a research I could suggest a better wording, but I don't care
   much if it's me or Felipe who comes up with a better text.

So all in all I'm still confident that my mail was OK.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Uwe Kleine-König]

Hi Russell,

On Tue, Jan 04, 2011 at 05:33:01PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 04, 2011 at 03:00:31PM +0100, Uwe Kleine-K?nig wrote:
> > On Tue, Jan 04, 2011 at 02:02:55PM +0200, Felipe Balbi wrote:
> > > @@ -171,9 +168,6 @@ config FIQ
> > >  config ARCH_MTD_XIP
> > >  	bool
> > >  
> > > -config GENERIC_HARDIRQS_NO__DO_IRQ
> > > -	def_bool y
> > > -
> > You didn't mention this change in the commit log.  Is this duplicated,
> > too or did it just slip through?
> 
> If you look at kernel/irq/Kconfig (as I did with the original patch)
> you'd notice kernel/irq/Kconfig defines both of these symbols being
> removed when HAVE_GENERIC_HARDIRQS is enabled.
> 
> If you read the discussion in the previous version of this patch set,
> you'd notice that the removal of this was specifically requested.
> 
> It's very tiresome to have to re-explain these things.  Please take
> some more time to research the points you bring up, rather than
I don't agree here 100%.  IMHO the commit log was not good enough for
the change introduced by the patch (and Felipe's reply suggests that he
agrees).  I could still research it, but:

 - it was not obvious for me there was a previous version (no "v2" or
   similar in the patch subject);
 - for me it would take say 5 minutes to check, the author knows
   the answer to my question immediately (at least he should);
 - after a research I could suggest a better wording, but I don't care
   much if it's me or Felipe who comes up with a better text.

So all in all I'm still confident that my mail was OK.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

Hi,

On Tue, Jan 04, 2011 at 09:54:45PM +0100, Uwe Kleine-König wrote:
> > If you look at kernel/irq/Kconfig (as I did with the original patch)
> > you'd notice kernel/irq/Kconfig defines both of these symbols being
> > removed when HAVE_GENERIC_HARDIRQS is enabled.
> > 
> > If you read the discussion in the previous version of this patch set,
> > you'd notice that the removal of this was specifically requested.
> > 
> > It's very tiresome to have to re-explain these things.  Please take
> > some more time to research the points you bring up, rather than
> I don't agree here 100%.  IMHO the commit log was not good enough for
> the change introduced by the patch (and Felipe's reply suggests that he
> agrees).  I could still research it, but:
> 
>  - it was not obvious for me there was a previous version (no "v2" or
>    similar in the patch subject);
>  - for me it would take say 5 minutes to check, the author knows
>    the answer to my question immediately (at least he should);
>  - after a research I could suggest a better wording, but I don't care
>    much if it's me or Felipe who comes up with a better text.
> 
> So all in all I'm still confident that my mail was OK.

No need to fight over a simple change, here it is updated.

-- 
balbi

[-- Attachment #2: 0002-arm-Kconfig-remove-duplicated-GENERIC_HARDIRQS-entry.diff --]
[-- Type: text/x-diff, Size: 1494 bytes --]

>From cf332402a5476d7aaa9bada6b895430ba7bfa3fe Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Tue, 4 Jan 2011 12:38:24 +0200
Subject: [PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry
Organization: Texas Instruments\n

GENERIC_HARDIRQS is defined under kernel/irq/Kconfig,
so it's safe to drop the duplicated entry and simply
select HAVE_GENERIC_HARDIRQS. While at that, also
remove GENERIC_HARDIRQS_NO__DO_IRQ because it's also
defined under kernel/irq/Kconfig when
HAVE_GENERIC_HARDIRQS is selected.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/Kconfig |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d56d21c0..e6f0f8b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -15,6 +15,7 @@ config ARM
 	select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
 	select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
 	select HAVE_GENERIC_DMA_COHERENT
+	select HAVE_GENERIC_HARDIRQS
 	select HAVE_KERNEL_GZIP
 	select HAVE_KERNEL_LZO
 	select HAVE_KERNEL_LZMA
@@ -88,10 +89,6 @@ config MCA
 	  <file:Documentation/mca.txt> (and especially the web page given
 	  there) before attempting to build an MCA bus kernel.
 
-config GENERIC_HARDIRQS
-	bool
-	default y
-
 config STACKTRACE_SUPPORT
 	bool
 	default y
@@ -171,9 +168,6 @@ config FIQ
 config ARCH_MTD_XIP
 	bool
 
-config GENERIC_HARDIRQS_NO__DO_IRQ
-	def_bool y
-
 config ARM_L1_CACHE_SHIFT_6
 	bool
 	help
-- 
1.7.3.4.598.g85356

[PATCH 2/4] arm: Kconfig: remove duplicated GENERIC_HARDIRQS entry

[Felipe Balbi]

Hi,

On Tue, Jan 04, 2011 at 09:54:45PM +0100, Uwe Kleine-K?nig wrote:
> > If you look at kernel/irq/Kconfig (as I did with the original patch)
> > you'd notice kernel/irq/Kconfig defines both of these symbols being
> > removed when HAVE_GENERIC_HARDIRQS is enabled.
> > 
> > If you read the discussion in the previous version of this patch set,
> > you'd notice that the removal of this was specifically requested.
> > 
> > It's very tiresome to have to re-explain these things.  Please take
> > some more time to research the points you bring up, rather than
> I don't agree here 100%.  IMHO the commit log was not good enough for
> the change introduced by the patch (and Felipe's reply suggests that he
> agrees).  I could still research it, but:
> 
>  - it was not obvious for me there was a previous version (no "v2" or
>    similar in the patch subject);
>  - for me it would take say 5 minutes to check, the author knows
>    the answer to my question immediately (at least he should);
>  - after a research I could suggest a better wording, but I don't care
>    much if it's me or Felipe who comes up with a better text.
> 
> So all in all I'm still confident that my mail was OK.

No need to fight over a simple change, here it is updated.

-- 
balbi

[PATCH 3/4] arm: Kconfig: remove duplicated SPARSE_IRQ entry

[Felipe Balbi]

SPARSE_IRQ is defined under kernel/irq/Kconfig so
it's safe to remove the duplicated entry.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/Kconfig |   13 ++-----------
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e6f0f8b..106d9f6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -504,7 +504,7 @@ config ARCH_MMP
 	select GENERIC_CLOCKEVENTS
 	select TICK_ONESHOT
 	select PLAT_PXA
-	select SPARSE_IRQ
+	select HAVE_SPARSE_IRQ
 	help
 	  Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line.
 
@@ -583,7 +583,7 @@ config ARCH_PXA
 	select GENERIC_CLOCKEVENTS
 	select TICK_ONESHOT
 	select PLAT_PXA
-	select SPARSE_IRQ
+	select HAVE_SPARSE_IRQ
 	help
 	  Support for Intel/Marvell's PXA2xx/PXA3xx processor line.
 
@@ -1392,15 +1392,6 @@ config HW_PERF_EVENTS
 	  Enable hardware performance counter support for perf events. If
 	  disabled, perf events will use software events only.
 
-config SPARSE_IRQ
-	def_bool n
-	help
-	  This enables support for sparse irqs. This is useful in general
-	  as most CPUs have a fairly sparse array of IRQ vectors, which
-	  the irq_desc then maps directly on to. Systems with a high
-	  number of off-chip IRQs will want to treat this as
-	  experimental until they have been independently verified.
-
 source "mm/Kconfig"
 
 config FORCE_MAX_ZONEORDER
-- 
1.7.3.4.598.g85356

[PATCH 3/4] arm: Kconfig: remove duplicated SPARSE_IRQ entry

[Felipe Balbi]

SPARSE_IRQ is defined under kernel/irq/Kconfig so
it's safe to remove the duplicated entry.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/Kconfig |   13 ++-----------
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e6f0f8b..106d9f6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -504,7 +504,7 @@ config ARCH_MMP
 	select GENERIC_CLOCKEVENTS
 	select TICK_ONESHOT
 	select PLAT_PXA
-	select SPARSE_IRQ
+	select HAVE_SPARSE_IRQ
 	help
 	  Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line.
 
@@ -583,7 +583,7 @@ config ARCH_PXA
 	select GENERIC_CLOCKEVENTS
 	select TICK_ONESHOT
 	select PLAT_PXA
-	select SPARSE_IRQ
+	select HAVE_SPARSE_IRQ
 	help
 	  Support for Intel/Marvell's PXA2xx/PXA3xx processor line.
 
@@ -1392,15 +1392,6 @@ config HW_PERF_EVENTS
 	  Enable hardware performance counter support for perf events. If
 	  disabled, perf events will use software events only.
 
-config SPARSE_IRQ
-	def_bool n
-	help
-	  This enables support for sparse irqs. This is useful in general
-	  as most CPUs have a fairly sparse array of IRQ vectors, which
-	  the irq_desc then maps directly on to. Systems with a high
-	  number of off-chip IRQs will want to treat this as
-	  experimental until they have been independently verified.
-
 source "mm/Kconfig"
 
 config FORCE_MAX_ZONEORDER
-- 
1.7.3.4.598.g85356

[PATCH 4/4] arm: Kconfig: allow OMAP to use sparse IRQ numbering

[Felipe Balbi]

Select HAVE_SPARSE_IRQ to allow OMAP to use
sparse IRQ numbering scheme. The main difference
is that irq_descs will be added to a radix tree
instead of a static array.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 106d9f6..2413aa6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -820,6 +820,7 @@ config ARCH_DAVINCI
 config ARCH_OMAP
 	bool "TI OMAP"
 	select HAVE_CLK
+	select HAVE_SPARSE_IRQ
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
 	select GENERIC_CLOCKEVENTS
-- 
1.7.3.4.598.g85356

[PATCH 4/4] arm: Kconfig: allow OMAP to use sparse IRQ numbering

[Felipe Balbi]

Select HAVE_SPARSE_IRQ to allow OMAP to use
sparse IRQ numbering scheme. The main difference
is that irq_descs will be added to a radix tree
instead of a static array.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 106d9f6..2413aa6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -820,6 +820,7 @@ config ARCH_DAVINCI
 config ARCH_OMAP
 	bool "TI OMAP"
 	select HAVE_CLK
+	select HAVE_SPARSE_IRQ
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_CPUFREQ
 	select GENERIC_CLOCKEVENTS
-- 
1.7.3.4.598.g85356