From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [question] NR_IRQS in genirq
Date: Wed, 24 Nov 2010 14:00:49 +0000 [thread overview]
Message-ID: <20101124140048.GG24970@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <alpine.LFD.2.00.1011241453330.2900@localhost6.localdomain6>
On Wed, Nov 24, 2010 at 02:54:38PM +0100, Thomas Gleixner wrote:
> On Wed, 24 Nov 2010, Mark Brown wrote:
> > On Wed, Nov 24, 2010 at 09:46:06PM +0800, Haojian Zhuang wrote:
> > Most ARM platforms have come up with some Kconfig gunk to allow boards
> > to extend this for off-SoC GPIOs. It'd be really nice to get rid of
> > NR_IRQS and stop having to worry about this at all :(
> I mean with sparse_irq you can set NR_IRQS insanely high w/o
> increasing memory consumption. That's the whole point.
Yeah, I was just pointing out common practice on ARM (sparse IRQ isn't
widely enough deployed there :/ ).
Would it be worth having sparse_irq change the default NR_IRQS to be
something suitably large - there doesn't seem any point in having
platforms using it each pick their own particular definition of insanely
high? I'll take a look and cook up a patch unless I can spot anything
silly about that by myself.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [question] NR_IRQS in genirq
Date: Wed, 24 Nov 2010 14:00:49 +0000 [thread overview]
Message-ID: <20101124140048.GG24970@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <alpine.LFD.2.00.1011241453330.2900@localhost6.localdomain6>
On Wed, Nov 24, 2010 at 02:54:38PM +0100, Thomas Gleixner wrote:
> On Wed, 24 Nov 2010, Mark Brown wrote:
> > On Wed, Nov 24, 2010 at 09:46:06PM +0800, Haojian Zhuang wrote:
> > Most ARM platforms have come up with some Kconfig gunk to allow boards
> > to extend this for off-SoC GPIOs. It'd be really nice to get rid of
> > NR_IRQS and stop having to worry about this at all :(
> I mean with sparse_irq you can set NR_IRQS insanely high w/o
> increasing memory consumption. That's the whole point.
Yeah, I was just pointing out common practice on ARM (sparse IRQ isn't
widely enough deployed there :/ ).
Would it be worth having sparse_irq change the default NR_IRQS to be
something suitably large - there doesn't seem any point in having
platforms using it each pick their own particular definition of insanely
high? I'll take a look and cook up a patch unless I can spot anything
silly about that by myself.
next prev parent reply other threads:[~2010-11-24 14:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-24 7:28 [question] NR_IRQS in genirq Haojian Zhuang
2010-11-24 8:46 ` Paul Mundt
2010-11-24 13:56 ` Thomas Gleixner
2010-11-24 13:18 ` Thomas Gleixner
2010-11-24 13:46 ` Haojian Zhuang
2010-11-24 13:46 ` Haojian Zhuang
2010-11-24 13:50 ` Mark Brown
2010-11-24 13:50 ` Mark Brown
2010-11-24 13:54 ` Thomas Gleixner
2010-11-24 13:54 ` Thomas Gleixner
2010-11-24 14:00 ` Mark Brown [this message]
2010-11-24 14:00 ` Mark Brown
2010-11-24 13:53 ` Thomas Gleixner
2010-11-24 13:53 ` Thomas Gleixner
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=20101124140048.GG24970@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.