linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mbohan@codeaurora.org (Michael Bohan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: irq: Allow for specification of no preallocated irqs
Date: Thu, 19 Jan 2012 16:29:43 -0800	[thread overview]
Message-ID: <4F18B577.8080101@codeaurora.org> (raw)
In-Reply-To: <4F18A18C.9090302@gmail.com>

On 1/19/2012 3:04 PM, Rob Herring wrote:
> No doubt that arch_probe_nr_irqs is doing the wrong thing on ARM, but no
> pre-allocation is not what we want either. We ultimately want
> arch_probe_nr_irqs to return NR_IRQS_LEGACY (16) to reserve IRQ0 (aka
> NO_IRQ) and legacy ISA IRQs. With my series, NR_IRQS is set to
> NR_IRQS_LEGACY for SPARSE_IRQ. You can accomplish the same thing without
> that series by setting .nr_irqs to NR_IRQS for non-DT and to
> NR_IRQS_LEGACY for DT. For platforms to work in single kernel builds,
> they will need to select SPARSE_IRQ.

One issue here is that IRQ_BITMAP_BITS is defined as a function of 
NR_IRQS. Currently, there's a hack in place that arbitrarily tacks on 
8196 bits to the end, giving the max virq supported as 8212 with your 
patches. Unfortunately, the system I'm running on will require higher 
values than that, so this actually breaks me.

It seems like the right solution to this problem is to have the 
allocated_irqs bitmap expandable at runtime. Or perhaps use a different 
data structure to begin with?

Mike

  reply	other threads:[~2012-01-20  0:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-19 22:43 [PATCH] arm: irq: Allow for specification of no preallocated irqs Michael Bohan
2012-01-19 22:57 ` Russell King - ARM Linux
2012-01-19 23:04 ` Rob Herring
2012-01-20  0:29   ` Michael Bohan [this message]
2012-01-20 13:54     ` Rob Herring
2012-01-20 16:15     ` Grant Likely

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=4F18B577.8080101@codeaurora.org \
    --to=mbohan@codeaurora.org \
    --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 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).