ARM IRQ Changes

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 <[email protected]>

---
 arch/arm/plat-omap/gpio.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

arch/arm/plat-omap/gpio.c +7 -3

index c05c653..c351758 100644
@@ -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);

Quoted 6 lines · 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 <[email protected]>

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.

Quoted 13 lines · Kevin Hilman

Quoted 6 lines · 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 <[email protected]>

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.

Quoted 3 lines

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.

From 8d216ccac14e4eebf259d5b40ed2d239248710e1 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <[email protected]>
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 <[email protected]>

---
 arch/arm/plat-omap/gpio.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

arch/arm/plat-omap/gpio.c +7 -3

index 1f98e0b..197a6c0 100644
@@ -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);

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 <[email protected]>

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

arch/arm/Kconfig +1 -4

index d56d21c0..e6f0f8b 100644
@@ -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

Quoted 36 lines · 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 <[email protected]>

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

arch/arm/Kconfig +1 -4

index d56d21c0..e6f0f8b 100644
@@ -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
 

arch/arm/Kconfig config FIQ · line 176

Quoted 3 lines

arch/arm/Kconfig +0 -3

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

Quoted 36 lines · 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 <[email protected]>

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

arch/arm/Kconfig +1 -4

index d56d21c0..e6f0f8b 100644
@@ -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
 

arch/arm/Kconfig config FIQ · line 176

Quoted 3 lines

arch/arm/Kconfig +0 -3

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

Quoted 10 lines · Uwe Kleine-K?nig

arch/arm/Kconfig config FIQ · line 176

Quoted 7 lines · Felipe Balbi

arch/arm/Kconfig +0 -3

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

Quoted 9 lines

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.