All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Bohan <mbohan@codeaurora.org>
To: Rob Herring <robherring2@gmail.com>
Cc: grant.likely@secretlab.ca, tglx@linutronix.de,
	Russell King <linux@arm.linux.org.uk>,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [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

WARNING: multiple messages have this Message-ID (diff)
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: 12+ 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:43 ` Michael Bohan
2012-01-19 22:57 ` Russell King - ARM Linux
2012-01-19 22:57   ` Russell King - ARM Linux
2012-01-19 23:04 ` Rob Herring
2012-01-19 23:04   ` Rob Herring
2012-01-20  0:29   ` Michael Bohan [this message]
2012-01-20  0:29     ` Michael Bohan
2012-01-20 13:54     ` Rob Herring
2012-01-20 13:54       ` Rob Herring
2012-01-20 16:15     ` Grant Likely
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=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=robherring2@gmail.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 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.