linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Milton Miller <miltonm@bga.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org
Subject: Re: genirq: Ensure we locate the passed IRQ in irq_alloc_descs()
Date: Sat, 4 Jun 2011 10:51:39 +0100	[thread overview]
Message-ID: <20110604095138.GA708@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <irq-locate-ack@mdm.bga.com>

On Fri, Jun 03, 2011 at 07:23:24PM -0500, Milton Miller wrote:
> On Fri, 3 Jun 2011 about 16:06:36 +0100, Mark Brown wrote:

> > I need either a specific IRQ or an allocated one.  This is just a very
> > standard driver with an interrupt controller 

> I don't know that I'd call an interrupt controller a standard driver
> today, but agree we are heading towards that.

Pretty much any modern ARM system will have a PMIC with an interrupt
controller in it.

> > The driver assumes it's going to get a contiguous range, it'd be a lot
> > of bookkeeping for no gain to have to cope with them being splattered
> > all over the place.

> The irq domain concept addresses mapping, but a simple fully allocated
> block will be one of the options.  Having 60 irqdesc might be 
> pushing the limit for some platforms but that can be addressed later
> when irq domains are upstream.

I'm not really sure what an IRQ domain is (the patch series you pointed
at before does rather appear to assume one knows already) but given that
we're allocating from within a 32 bit type it seems like we should be
using a few orders of magnitude more interrupts in a system than we do
presently before this becomes much of an issue.

> > If the user cares they can just pick a number for the base; if they're
> > going to pick a number they may as well pick the actual number.

> I'd argue the user is the wrong level to make this decision.  However,
> saying the platform decides is valid, and the excerpt you had earlier
> implied you were getting the irq argument from platform data, not the
> user (eg via a module parameter)..

It's platform data.  Having interrupt numbers specified as module
parameters strikes me as insane - the particular integers we map
individual interrupts onto are very much an implementation decision of
the kernel.

> I should point out that several archtectures currently allocate irqs
> in a architecture layer before calling the irq allocator asking for
> the exact irq they choose on what they thought was free.  Among these
> are x86 and powerpc.   Not calling the architecture layer will causein
> all future allocations by other drivers using the architecture layer
> to fail..

That sounds like we should join the two IRQ allocators up with each
other.

  reply	other threads:[~2011-06-04  9:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02 17:55 [PATCH] genirq: Ensure we locate the passed IRQ in irq_alloc_descs() Mark Brown
2011-06-03  9:24 ` Milton Miller
2011-06-03 10:42   ` Mark Brown
2011-06-03 14:43     ` Milton Miller
2011-06-03 15:06       ` Mark Brown
2011-06-03 16:25       ` Thomas Gleixner
2011-06-04  0:23         ` Milton Miller
2011-06-04  9:51           ` Mark Brown [this message]
2011-06-06 19:42             ` Grant Likely
2011-06-06 20:57               ` Mark Brown
2011-06-06 21:33                 ` Grant Likely
2011-06-03 12:59 ` [tip:irq/urgent] " tip-bot for Mark Brown

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=20110604095138.GA708@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miltonm@bga.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).