public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [RFC] killing the NR_IRQS arrays.
Date: Sat, 17 Feb 2007 15:00:47 +1100	[thread overview]
Message-ID: <1171684847.5644.108.camel@localhost.localdomain> (raw)
In-Reply-To: <200702170237.42910.arnd@arndb.de>

On Sat, 2007-02-17 at 02:37 +0100, Arnd Bergmann wrote:
> On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote:
> > You might want to have a look at the powerpc API with it's remaping
> > capabilities. It's very nice for handling multiple domain spaces. It
> > might be of some use for you.
> 
> I don't consider the powerpc virtual IRQs a solution for the problem.
> While I believe you did the right thing for powerpc with generalizing
> this over all its platforms, it really isn't more than a workaround
> for the problem that we can't deal well with the static irq_desc
> array.

It's not a solution per-se, though it contains elements of solution like
the reverse mappin, which I use to map HW numbers to virtual irqs but
can trivially adapt to map HW numbers to irq_desc pointers.

Among other things, I want to make sure that we don't end up with just
putting an irq number in a field of the irq_desc and have half of the
drivers peek at it and assume we can convert between irq_desc* and
number in arbitrary ways.

The HW irq number should be as much opaque as possible from the world
outside of the PIC code and/or arch code that assign them. That's an
area where the powerpc and/or sparc code might be of use.


> When that problem is now getting worse on other architectures, we
> should try to get it right on all of them, rather than spreading
> the workaround further.

Yes, but I'd like aspects of my remapping work to be included in
whatever we come up with, which is to have the new irq_desc either hide
the underlying HW number, or at least associate it make it very clear
that it's an opaque token and not guaranteed to be unique accross
multiple PICs in the system.

In addition, if we remove the numbers, archs will need basically the
exact same services provided by the powerpc irq core for reverse mapping
(going from a HW irq number on a given PIC back to an irq_desc *).

Either using a linear array for simple PICs or a radix tree for
platforms with very big interrupt numbers (BTW. I think we have lockless
radix trees nowadays, I can remove the spinlocks to protect it in the
powerpc remapper).

Ben.



  reply	other threads:[~2007-02-17  4:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16 12:10 [RFC] killing the NR_IRQS arrays Eric W. Biederman
2007-02-16 12:16 ` Andi Kleen
2007-02-16 15:35   ` Eric W. Biederman
2007-02-16 12:41 ` Ingo Molnar
2007-02-16 15:23   ` Eric W. Biederman
2007-02-16 15:49   ` Eric W. Biederman
2007-02-16 22:33   ` Benjamin Herrenschmidt
2007-02-18 21:24   ` Arjan van de Ven
2007-02-19  0:25     ` Benjamin Herrenschmidt
2007-02-27 20:29       ` Eric W. Biederman
2007-02-28  0:41         ` Arnd Bergmann
2007-02-28  7:20           ` Eric W. Biederman
2007-02-28  8:09             ` Benjamin Herrenschmidt
2007-02-28 13:28               ` Eric W. Biederman
2007-02-28 12:24             ` Arnd Bergmann
2007-02-28 13:02               ` Segher Boessenkool
2007-02-28 13:53               ` Eric W. Biederman
2007-03-01 10:47                 ` Benjamin Herrenschmidt
2007-02-16 18:07 ` Jeremy Fitzhardinge
2007-02-16 19:01   ` Eric W. Biederman
2007-02-16 19:06     ` Jeremy Fitzhardinge
2007-02-16 19:45 ` Arnd Bergmann
2007-02-16 19:52   ` Russell King
2007-02-16 20:43     ` Arnd Bergmann
2007-02-16 20:59       ` Russell King
2007-02-16 22:37     ` Benjamin Herrenschmidt
2007-02-17  1:37       ` Arnd Bergmann
2007-02-17  4:00         ` Benjamin Herrenschmidt [this message]
2007-02-17  9:06           ` Eric W. Biederman
2007-02-17 21:15             ` Benjamin Herrenschmidt
2007-02-18  6:30               ` Eric W. Biederman
2007-02-18 20:01                 ` Benjamin Herrenschmidt
2007-02-17  9:34     ` Eric W. Biederman
2007-02-17 21:20       ` Benjamin Herrenschmidt
2007-02-18  3:58         ` Eric W. Biederman
2007-02-16 22:29 ` Benjamin Herrenschmidt
2007-02-17  8:51   ` Eric W. Biederman
2007-02-17 21:04     ` Benjamin Herrenschmidt
2007-02-18  4:58       ` Eric W. Biederman
2007-02-18 19:58         ` Benjamin Herrenschmidt

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=1171684847.5644.108.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=ebiederm@xmission.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=torvalds@linux-foundation.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