From: Arnd Bergmann <arnd@arndb.de>
To: michaele@au1.ibm.com
Cc: benh@kernel.crashing.org, Matthew Wilcox <matthew@wil.cx>,
linux-pci@vger.kernel.org,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
David Miller <davem@davemloft.net>,
Dan Williams <dan.j.williams@intel.com>,
Martine.Silbermann@hp.com, linux-kernel@vger.kernel.org
Subject: Re: Multiple MSI
Date: Thu, 3 Jul 2008 11:10:29 +0200 [thread overview]
Message-ID: <200807031110.30072.arnd@arndb.de> (raw)
In-Reply-To: <1215067484.17950.35.camel@localhost>
On Thursday 03 July 2008, Michael Ellerman wrote:
> On Thu, 2008-07-03 at 14:41 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-07-02 at 21:59 -0600, Matthew Wilcox wrote:
> > >
> > >
> > > This is true and worth considering carefully. Are IRQ numbers a scarce
> > > resource on PowerPC? They are considerably less scarce than interrupt
> > > vectors are on x86-64. How hard is it to make IRQ numbers an abundent
> > > resource? Is it simply a question of increasing NR_IRQS?
> >
> > Yes, indeed, they aren't really scarce... actually less than the
> > underlying HW vectors in most cases, so it isn't a big issue to add some
> > kind of constraint to the allocator.
>
> Not scarce, but increasing NR_IRQS makes some static arrays bigger,
> which is not so nice.
Some years ago, we had discussions about getting rid of IRQ numbers
altogether, or at least the requirement to have device drivers know
about them. Does anyone remember what happened to that idea?
I think the concept was that you pass around struct irq_desc pointers
that may or may not be dynamically allocated by the interrupt controller
code.
Another simplification that should really help here is encapsulating
request_irq() per subsystem so that you can do something like
int my_irq(struct pci_dev *dev);
err = pci_request_irq(pci_dev, &my_irq, IRQF_SHARED);
Most PCI drivers should be trivial to convert to this model. If you want
to have multiple MSI/MSI-X interrupts for one PCI device with this model,
you'd need to introduce the number back as an offset, I guess.
Arnd <><
next prev parent reply other threads:[~2008-07-03 12:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-03 2:44 Multiple MSI Matthew Wilcox
2008-07-03 3:24 ` Benjamin Herrenschmidt
2008-07-03 3:59 ` Matthew Wilcox
2008-07-03 4:41 ` Benjamin Herrenschmidt
2008-07-03 6:44 ` Michael Ellerman
2008-07-03 9:10 ` Arnd Bergmann [this message]
2008-07-03 9:17 ` Benjamin Herrenschmidt
2008-07-03 11:31 ` Matthew Wilcox
2008-07-03 11:41 ` Benjamin Herrenschmidt
2008-07-04 1:52 ` Michael Ellerman
2008-07-04 8:08 ` Alan Cox
2008-07-03 11:34 ` Matthew Wilcox
2008-07-07 16:17 ` Grant Grundler
2008-07-07 16:39 ` Matthew Wilcox
2008-07-07 16:51 ` Grant Grundler
2008-07-07 23:06 ` Benjamin Herrenschmidt
2008-07-10 0:55 ` Michael Ellerman
2008-07-05 13:27 ` Matthew Wilcox
2008-07-05 13:34 ` [PATCH 1/4] PCI MSI: Store the number of messages in the msi_desc Matthew Wilcox
2008-07-07 2:05 ` Michael Ellerman
2008-07-07 2:41 ` Matthew Wilcox
2008-07-07 3:26 ` Benjamin Herrenschmidt
2008-07-07 3:48 ` Michael Ellerman
2008-07-07 12:04 ` Matthew Wilcox
2008-07-07 16:02 ` Grant Grundler
2008-07-07 16:19 ` Matthew Wilcox
2008-07-10 1:32 ` Michael Ellerman
2008-07-10 1:35 ` Matthew Wilcox
2008-07-05 13:34 ` [PATCH 2/4] PCI: Support multiple MSI Matthew Wilcox
2008-07-07 2:05 ` Michael Ellerman
2008-07-07 2:45 ` Matthew Wilcox
2008-07-07 3:56 ` Michael Ellerman
2008-07-07 11:31 ` Matthew Wilcox
2008-07-10 1:32 ` Michael Ellerman
2008-07-10 1:43 ` Matthew Wilcox
2008-07-10 4:00 ` Michael Ellerman
2008-07-05 13:34 ` [PATCH 3/4] AHCI: Request multiple MSIs Matthew Wilcox
2008-07-07 16:45 ` Grant Grundler
2008-07-07 17:48 ` Matthew Wilcox
2008-07-20 7:49 ` Grant Grundler
2008-07-05 13:34 ` [PATCH 4/4] x86-64: Support for " Matthew Wilcox
2008-07-05 13:43 ` Multiple MSI Matthew Wilcox
2008-07-05 22:38 ` Matthew Wilcox
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=200807031110.30072.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=Martine.Silbermann@hp.com \
--cc=benh@kernel.crashing.org \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=michaele@au1.ibm.com \
--cc=mingo@elte.hu \
--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