ARM: OMAP: IRQ domain support for INTC

GIT PULL Cousson, Benoit 3 participants 8 messages Feb 27, 2012 – Mar 5, 2012 GPIO

lore

Share & tools

lore

Cousson, Benoit

author

2012-02-27 16:36 UTC #0 lore raw

Hi Tony

This series is based on the lo/dt + the irqdomain/next branch merged on top of it.

Grant confirmed that the irqdomain/next is a stable branch and thus can be referenced for dependency.

Please note that I will need that branch to base all the remaining OMAP DT stuff.

Thanks,
Benoit

The following changes since commit 1f52299ec000e2161635b263d81ab92ea7f1f0a7:
Benoit Cousson (1):
Merge branch 'irqdomain/next' of git://git.secretlab.ca/git/linux-2.6 into for_3.4/dt_irq_domain2

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_irq_domain

Benoit Cousson (3):
ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC
ARM: OMAP2+: board-generic: Use of_irq_init API

 .../devicetree/bindings/arm/omap/intc.txt          |   27 +++++++++
 arch/arm/boot/dts/omap3.dtsi                       |    6 +-
 arch/arm/mach-omap2/board-generic.c                |   30 +++++-----
 arch/arm/mach-omap2/common.h                       |   12 ++++
 arch/arm/mach-omap2/irq.c                          |   60 ++++++++++++++++---
 5 files changed, 109 insertions(+), 26 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt

Cousson, Benoit

author

2012-02-29 16:15 UTC #2 lore raw

Hi Tony,

Quoted 36 lines · Tony Lindgren

Hi,
Quoted 25 lines · Cousson, Benoit
Hi Tony
This series is based on the lo/dt + the irqdomain/next branch merged on top of it.
Grant confirmed that the irqdomain/next is a stable branch and thus can be referenced for dependency.
Please note that I will need that branch to base all the remaining OMAP DT stuff.
Thanks,
Benoit
The following changes since commit 1f52299ec000e2161635b263d81ab92ea7f1f0a7:
Benoit Cousson (1):
Merge branch 'irqdomain/next' of git://git.secretlab.ca/git/linux-2.6 into for_3.4/dt_irq_domain2
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_irq_domain
Benoit Cousson (3):
ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC
ARM: OMAP2+: board-generic: Use of_irq_init API
Quoted 7 lines
  .../devicetree/bindings/arm/omap/intc.txt          |   27 +++++++++
  arch/arm/boot/dts/omap3.dtsi                       |    6 +-
  arch/arm/mach-omap2/board-generic.c                |   30 +++++-----
  arch/arm/mach-omap2/common.h                       |   12 ++++
  arch/arm/mach-omap2/irq.c                          |   60 ++++++++++++++++---
  5 files changed, 109 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt

Quoted 1 line

Hmm, looks like this now produces the following warning at least on omap3:

Yes, Rajendra has just reported that issue with linux-next.

It is not due to that series but to the increase of TWL irq_desc I did for Grant to fix a warning with irq_domain in the DT boot. Unfortunately due the lack of NR_IRQS we already have becasue of PRCM handler we exceed the actual NR_IRQS that is set to 410 for the moment.

Quoted 2 lines

[    0.290832] WARNING: at drivers/mfd/twl4030-irq.c:645 twl4030_sih_setup+0x258/0x298()
[    0.290832] irq 428 for gpio too big

After applying the NR_IRQS fix, we still have a warning but a different one in that case:

[    0.303771] twl4030: PIH (irq 7) chaining IRQs 368..401
[    0.304473] twl4030: power (irq 373) chaining IRQs 402..409
[    0.307159] twl4030: gpio (irq 368) chaining IRQs 410..427
[    0.307189] ------------[ cut here ]------------
[    0.307220] WARNING: at drivers/gpio/gpio-twl4030.c:410 gpio_twl4030_probe+0x44/0x214()

This one is due to a "WARN_ON(ret != pdata->irq_base)" that is checking that the board irq_base is the same as the one from the twl4030_sih_setup. This kind of test are not SPARSE_IRQ friendly at all and should be removed anyway. I've attached a patch to fix the GPIO warning.

Felipe has started a twl4030 IRQ cleanup series to make that driver SPARSE_IRQ enabled. That's will fix properly the actual hack in the twl-core IRQ management. On top of that we can fix the twl-gpio warning.

Regards,
Benoit

---

Quoted 1 line

From 13bf5df12ea6dd0dded45bd4ee4d2508f5f2712c Mon Sep 17 00:00:00 2001

From: Benoit Cousson <[email protected]>
Date: Tue, 28 Feb 2012 21:51:59 +0100
Subject: [PATCH] gpio/twl: Fix IRQ setup to be SPARSE_IRQ friendly

Since the SIH handler is allocating irq_descs dynamically, the irq_base cannot be defined anymore by the board through pdata.

Remove the test to setup IRQ only in case of valid pdata. Remove the check to ensure irq_base is the one from pdata.

Signed-off-by Benoit Cousson <[email protected]>

Cc Felipe Balbi <[email protected]>

---
 drivers/gpio/gpio-twl4030.c |   21 ++++++++++-----------
 1 files changed, 10 insertions(+), 11 deletions(-)

drivers/gpio/gpio-twl4030.c +10 ~~-11~~

index b8b4f22..0f7d29c 100644
@@ -398,19 +398,18 @@ static int __devinit gpio_twl4030_probe(struct platform_device *pdev)
 	int ret;
 
 	/* maybe setup IRQs */
-	if (pdata->irq_base) {
-		if (is_module()) {
-			dev_err(&pdev->dev,
-				"can't dispatch IRQs from modules\n");
-			goto no_irqs;
-		}
-		ret = twl4030_sih_setup(TWL4030_MODULE_GPIO);
-		if (ret < 0)
-			return ret;
-		WARN_ON(ret != pdata->irq_base);
-		twl4030_gpio_irq_base = ret;
+	if (is_module()) {
+		dev_err(&pdev->dev,
+			"can't dispatch IRQs from modules\n");
+		goto no_irqs;
 	}
 
+	ret = twl4030_sih_setup(TWL4030_MODULE_GPIO);
+	if (ret < 0)
+		return ret;
+
+	twl4030_gpio_irq_base = ret;
+
 no_irqs:
 	/*
 	 * NOTE:  boards may waste power if they don't set pullups

Signature · 1 line

1.7.0.4

Tony Lindgren

2012-02-29 21:42 UTC #3 lore raw

Quoted 11 lines · Cousson, Benoit

Quoted 2 lines · Tony Lindgren
Hmm, looks like this now produces the following warning at least on omap3:
Yes, Rajendra has just reported that issue with linux-next.
It is not due to that series but to the increase of TWL irq_desc I did for Grant to fix a warning with irq_domain in the DT boot. Unfortunately due the lack of NR_IRQS we already have becasue of PRCM handler we exceed the actual NR_IRQS that is set to 410 for the moment.
Quoted 2 lines
[    0.290832] WARNING: at drivers/mfd/twl4030-irq.c:645 twl4030_sih_setup+0x258/0x298()
[    0.290832] irq 428 for gpio too big

OK. I've pulled this into dt-part2 branch.

Quoted 9 lines

After applying the NR_IRQS fix, we still have a warning but a different one in that case:
[    0.303771] twl4030: PIH (irq 7) chaining IRQs 368..401
[    0.304473] twl4030: power (irq 373) chaining IRQs 402..409
[    0.307159] twl4030: gpio (irq 368) chaining IRQs 410..427
[    0.307189] ------------[ cut here ]------------
[    0.307220] WARNING: at drivers/gpio/gpio-twl4030.c:410 gpio_twl4030_probe+0x44/0x214()
This one is due to a "WARN_ON(ret != pdata->irq_base)" that is checking that the board irq_base is the same as the one from the twl4030_sih_setup. This kind of test are not SPARSE_IRQ friendly at all and should be removed anyway. I've attached a patch to fix the GPIO warning.

OK, maybe post that separately so Samuel can queue it?

Quoted 1 line

Felipe has started a twl4030 IRQ cleanup series to make that driver SPARSE_IRQ enabled. That's will fix properly the actual hack in the twl-core IRQ management. On top of that we can fix the twl-gpio warning.

Great, good to hear.

Regards,

Tony

Johan Hovold

2012-03-05 13:58 UTC #4 lore raw

In reply to Cousson, Benoit

Quoted 35 lines · Benoit

Quoted 34 lines · Tony Lindgren
Quoted 32 lines · Cousson, Benoit
Hi Tony
This series is based on the lo/dt + the irqdomain/next branch merged on top of it.
Grant confirmed that the irqdomain/next is a stable branch and thus can be referenced for dependency.
Please note that I will need that branch to base all the remaining OMAP DT stuff.
Thanks,
Benoit
The following changes since commit 1f52299ec000e2161635b263d81ab92ea7f1f0a7:
Benoit Cousson (1):
Merge branch 'irqdomain/next' of git://git.secretlab.ca/git/linux-2.6 into for_3.4/dt_irq_domain2
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_irq_domain
Benoit Cousson (3):
ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC
ARM: OMAP2+: board-generic: Use of_irq_init API
  .../devicetree/bindings/arm/omap/intc.txt          |   27 +++++++++
  arch/arm/boot/dts/omap3.dtsi                       |    6 +-
  arch/arm/mach-omap2/board-generic.c                |   30 +++++-----
  arch/arm/mach-omap2/common.h                       |   12 ++++
  arch/arm/mach-omap2/irq.c                          |   60 ++++++++++++++++---
  5 files changed, 109 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt

Quoted 3 lines

Quoted 1 line
Hmm, looks like this now produces the following warning at least on omap3:
Yes, Rajendra has just reported that issue with linux-next.

I'm getting the same warning and initialisation failure with 3.3-rc6 on overo. Are these fixes queued up for 3.3 (and not just 3.4) somewhere?

Thanks,
Johan

Cousson, Benoit

author

2012-03-05 14:25 UTC #5 lore raw

Quoted 36 lines · Johan Hovold

Quoted 35 lines · Benoit
Quoted 34 lines · Tony Lindgren
Quoted 32 lines · Cousson, Benoit
Hi Tony
This series is based on the lo/dt + the irqdomain/next branch merged on top of it.
Grant confirmed that the irqdomain/next is a stable branch and thus can be referenced for dependency.
Please note that I will need that branch to base all the remaining OMAP DT stuff.
Thanks,
Benoit
The following changes since commit 1f52299ec000e2161635b263d81ab92ea7f1f0a7:
Benoit Cousson (1):
Merge branch 'irqdomain/next' of git://git.secretlab.ca/git/linux-2.6 into for_3.4/dt_irq_domain2
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_irq_domain
Benoit Cousson (3):
ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC
ARM: OMAP2+: board-generic: Use of_irq_init API
   .../devicetree/bindings/arm/omap/intc.txt          |   27 +++++++++
   arch/arm/boot/dts/omap3.dtsi                       |    6 +-
   arch/arm/mach-omap2/board-generic.c                |   30 +++++-----
   arch/arm/mach-omap2/common.h                       |   12 ++++
   arch/arm/mach-omap2/irq.c                          |   60 ++++++++++++++++---
   5 files changed, 109 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Hmm, looks like this now produces the following warning at least on omap3:
Yes, Rajendra has just reported that issue with linux-next.
I'm getting the same warning and initialisation failure with 3.3-rc6 on overo. Are these fixes queued up for 3.3 (and not just 3.4) somewhere?

It is under review, I posted the series last Friday:
mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect

It will be anyway material for 3.4 since it is in linux-next.

Regards,
Benoit

Johan Hovold

2012-03-05 15:03 UTC #6 lore raw

Quoted 8 lines · Benoit

Quoted 7 lines · Johan Hovold
Quoted 5 lines · Benoit
Quoted 2 lines · Tony Lindgren
* Cousson, Benoit<[email protected]> [120227 08:04]:
Hmm, looks like this now produces the following warning at least on omap3:
Yes, Rajendra has just reported that issue with linux-next.

Quoted 7 lines

Quoted 2 lines
I'm getting the same warning and initialisation failure with 3.3-rc6 on overo. Are these fixes queued up for 3.3 (and not just 3.4) somewhere?
It is under review, I posted the series last Friday:
mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect
It will be anyway material for 3.4 since it is in linux-next.

Yes, I noted that there was a fix against linux-next. My question was whether any fix is planned for 3.3 as twl4030 is broken with SPARSE_IRQ enabled.

Disabling SPARSE_IRQ will be the only workaround until 3.4 is out then?

Thanks,
Johan

Cousson, Benoit

author

2012-03-05 15:19 UTC #7 lore raw

Quoted 15 lines · Johan Hovold

Quoted 14 lines · Benoit
Quoted 9 lines · Johan Hovold
Quoted 5 lines · Benoit
Quoted 2 lines · Tony Lindgren
* Cousson, Benoit<[email protected]> [120227 08:04]:
Hmm, looks like this now produces the following warning at least on omap3:
Yes, Rajendra has just reported that issue with linux-next.
I'm getting the same warning and initialisation failure with 3.3-rc6 on overo. Are these fixes queued up for 3.3 (and not just 3.4) somewhere?
It is under review, I posted the series last Friday:
mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect

Quoted 7 lines

Quoted 1 line
It will be anyway material for 3.4 since it is in linux-next.
Yes, I noted that there was a fix against linux-next. My question was whether any fix is planned for 3.3 as twl4030 is broken with SPARSE_IRQ enabled.
Disabling SPARSE_IRQ will be the only workaround until 3.4 is out then?

Mmm, but is SPARSE_IRQ used to work before on OMAP3?

Benoit