public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "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>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Ingo Molnar <mingo@elte.hu>, Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [RFC] killing the NR_IRQS arrays.
Date: Fri, 16 Feb 2007 20:59:42 +0000	[thread overview]
Message-ID: <20070216205942.GG2572@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200702162143.25130.arnd@arndb.de>

On Fri, Feb 16, 2007 at 09:43:24PM +0100, Arnd Bergmann wrote:
> On Friday 16 February 2007 20:52, Russell King wrote:
> > On Fri, Feb 16, 2007 at 08:45:58PM +0100, Arnd Bergmann wrote:
> > > We did something like this a few years back on the s390 architecture, which
> > > happens to be lucky enough not to share any interrupt based drivers with
> > > any of the other architectures.
> > 
> > What you're proposing is looking similar to a proposal I put forward some
> > 4 years ago, but was rejected.  Maybe times have changed and there's a
> > need for it now.
> 
> Yes, I think times have changed, with the increased popularity of MSI
> and paravirtualized devices. A few points on your old proposal though:
> 
> - Doing it per architecture no longer sounds feasible, I think it would
>   need to be done per subsystem so that the drivers can be adapted to
>   a new interface, and most drivers are used across multiple architectures.
> - struct irq sounds much more fitting than struct irq_desc
> - creating new irq_foo() functions to replace foo_irq() also sounds right.
> - doing subsystem specific abstractions ideally allows the drivers to
>   not even need to worry about the irq pointer, significantly simplifying
>   the interface for register/unregister.

I agree with your points above, except for:

> - I don't see the point in splitting request_irq into irq_request and
>   irq_register.

This was to work around those scenarios where you want to mark an IRQ
resource as being in use prior to actually using it in much the same
way as is done with IO ports.

I've come across hardware where you need to claim the interrupt with
the controller masked, configure the device generating the interrupt
appropriately, and only then unmask it.  Otherwise you end up spinning.

To work around that, we've had to introduce additional flags into the
genirq subsystem - IRQF_NOAUTOEN - whereas separating the "obtain"
from the "start using" bit of request_irq would've made this
unnecessary.

Another example where this (was|still is) used is the IDE code, but
that's probably been cleaned up in some way now.

There's nothing wrong with keeping a combined "request_irq" for the
common case though.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  reply	other threads:[~2007-02-16 20:59 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 [this message]
2007-02-16 22:37     ` Benjamin Herrenschmidt
2007-02-17  1:37       ` Arnd Bergmann
2007-02-17  4:00         ` Benjamin Herrenschmidt
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=20070216205942.GG2572@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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