From: Felipe Balbi <balbi@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Felipe Balbi <balbi@ti.com>,
Linux OMAP Mailing List <linux-omap@vger.kernel.org>
Subject: Re: [RFT/PATCH 05/10] cbus: retu: move to threaded IRQ and GENIRQ
Date: Fri, 7 Jan 2011 09:48:14 +0200 [thread overview]
Message-ID: <20110107074814.GC3230@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <20110107030449.GH7771@atomide.com>
On Thu, Jan 06, 2011 at 07:04:50PM -0800, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [110104 22:37]:
> > Hi,
> >
> > On Tue, Jan 04, 2011 at 11:14:00AM -0800, Tony Lindgren wrote:
> > > I think there's been some patches related to this to get rid
> > > of NR_IRQS? Might be worth taking a look at those first as it's
> > > a generic solution.
> >
> > Yeah, one way would be to use Sparse IRQ numbering scheme and define
> > different bases for different IRQ chips. We could use for example,
> > something like:
> >
> > IRQ | Chip
> > =====================
> > 0-299 | INTC
> > 300-499 | TWL4030
> > 500-599 | MENELAUS
> > 600-799 | RETU
> > 800-999 | TAHVO
> >
> > and so on. But I'm not sure that's good enough (numbers are just from
> > the top of my head, didn't really check how many IRQs each one have).
> >
> > The only problem I see is with INTC, what happens if we give it an
> > interval which ends up not being big enough for next OMAP versions ?
>
> I think that's the way to go, but we should not allocate that
> many irqs.. We can define the ranges like we already do in irqs.h
> based on what gets compiled in. There are few more blocks though:
The main point of using Sparse IRQ numbering is exactly avoiding
pre-processor branches. Instead of defining ranges only when a device is
compile, we can always keep the range allocated no matter if the device
probes or not. So, I suggest dropping the ifdeffery on <plat/irqs.h> and
move that to something like below:
diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
index 65e20a6..c4fcd9d 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -367,49 +367,28 @@
/* External FPGA handles interrupts on Innovator boards */
#define OMAP_FPGA_IRQ_BASE (OMAP_IRQ_END)
-#ifdef CONFIG_MACH_OMAP_INNOVATOR
#define OMAP_FPGA_NR_IRQS 24
-#else
-#define OMAP_FPGA_NR_IRQS 0
-#endif
#define OMAP_FPGA_IRQ_END (OMAP_FPGA_IRQ_BASE + OMAP_FPGA_NR_IRQS)
/* External TWL4030 can handle interrupts on 2430 and 34xx boards */
#define TWL4030_IRQ_BASE (OMAP_FPGA_IRQ_END)
-#ifdef CONFIG_TWL4030_CORE
#define TWL4030_BASE_NR_IRQS 8
#define TWL4030_PWR_NR_IRQS 8
-#else
-#define TWL4030_BASE_NR_IRQS 0
-#define TWL4030_PWR_NR_IRQS 0
-#endif
#define TWL4030_IRQ_END (TWL4030_IRQ_BASE + TWL4030_BASE_NR_IRQS)
#define TWL4030_PWR_IRQ_BASE TWL4030_IRQ_END
#define TWL4030_PWR_IRQ_END (TWL4030_PWR_IRQ_BASE + TWL4030_PWR_NR_IRQS)
/* External TWL4030 gpio interrupts are optional */
#define TWL4030_GPIO_IRQ_BASE TWL4030_PWR_IRQ_END
-#ifdef CONFIG_GPIO_TWL4030
#define TWL4030_GPIO_NR_IRQS 18
-#else
-#define TWL4030_GPIO_NR_IRQS 0
-#endif
#define TWL4030_GPIO_IRQ_END (TWL4030_GPIO_IRQ_BASE + TWL4030_GPIO_NR_IRQS)
#define TWL6030_IRQ_BASE (OMAP_FPGA_IRQ_END)
-#ifdef CONFIG_TWL4030_CORE
#define TWL6030_BASE_NR_IRQS 20
-#else
-#define TWL6030_BASE_NR_IRQS 0
-#endif
#define TWL6030_IRQ_END (TWL6030_IRQ_BASE + TWL6030_BASE_NR_IRQS)
/* Total number of interrupts depends on the enabled blocks above */
-#if (TWL4030_GPIO_IRQ_END > TWL6030_IRQ_END)
-#define TWL_IRQ_END TWL4030_GPIO_IRQ_END
-#else
-#define TWL_IRQ_END TWL6030_IRQ_END
-#endif
+#define TWL_IRQ_END TWL4030_GPIO_IRQ_END
#define NR_IRQS TWL_IRQ_END
--
balbi
next prev parent reply other threads:[~2011-01-07 7:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-03 7:49 [RFT/PATCH 00/10] move retu to threaded IRQ Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 01/10] cbus: retu: give it a context structure Felipe Balbi
2011-01-04 1:40 ` Tony Lindgren
2011-01-04 6:51 ` Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 02/10] cbus: retu: get rid of retu-user.c Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 03/10] cbus: retu: move module_* close to the matching symbol Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 04/10] cbus: retu: cleanup error path Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 05/10] cbus: retu: move to threaded IRQ and GENIRQ Felipe Balbi
2011-01-04 1:40 ` Tony Lindgren
2011-01-04 6:52 ` Felipe Balbi
2011-01-04 7:46 ` Felipe Balbi
2011-01-04 7:47 ` Felipe Balbi
2011-01-04 19:14 ` Tony Lindgren
2011-01-05 6:37 ` Felipe Balbi
2011-01-07 3:04 ` Tony Lindgren
2011-01-07 7:48 ` Felipe Balbi [this message]
2011-01-07 17:04 ` Tony Lindgren
2011-01-07 19:15 ` Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 06/10] cbus: retu: headset: convert to threaded_irq Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 07/10] cbus: retu-pwrbutton: convert to threaded irq Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 08/10] cbus: retu-rtc: move " Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 09/10] cbus: retu-rtc: drop the reset_occurred flag Felipe Balbi
2011-01-03 7:49 ` [RFT/PATCH 10/10] cbus: Makefile: re-enable retu-wdt Felipe Balbi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110107074814.GC3230@legolas.emea.dhcp.ti.com \
--to=balbi@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox