From: Matt Porter <mporter@kernel.crashing.org>
To: Matthew Wilcox <willy@debian.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
linux-kernel@vger.kernel.org,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
davem@redhat.com
Subject: Re: Message Signalled Interrupt support?
Date: Mon, 12 May 2003 10:43:00 -0700 [thread overview]
Message-ID: <20030512104300.A23510@home.com> (raw)
In-Reply-To: <20030512165331.GZ29534@parcelfarce.linux.theplanet.co.uk>; from willy@debian.org on Mon, May 12, 2003 at 05:53:31PM +0100
On Mon, May 12, 2003 at 05:53:31PM +0100, Matthew Wilcox wrote:
> On Mon, May 12, 2003 at 12:32:49PM -0400, Jeff Garzik wrote:
> > Has anybody done any work, or put any thought, into MSI support?
>
> Work -- no. Thought? A little. Seems to me that MSIs need to be treated
> as a third form of interrupts (level/edge/message). The address that
> the MSI will write to is clearly architecture dependent (may even be
> irq-controller-dependent, depending on your architecture). request_irq()
> is an insufficient function to deal with this -- request_msi() may be
> needed instead. It'll need to return an address to pass to the card.
> (We need a mechanism to decide whether it's a 32-bit or 64-bit address).
I've also done some thought for PPC440xx's PCI MSI support. It isn't
strictly necessary to have a new request_msi() if the kernel "does
the right thing". request_irq() already hooks using an interrupt
value that is virtual on many platforms. In that case, the PCI
subsystem would only need to provide an interface to provide
the architecture/platform specific inbound MSI location. The PCI
subsystem would then find all MSI capable PCI devices, and assign
the appropriate number of unique messages and inbound MSI address
to each device via the speced PCI MSI interface. The PCI subsystem
would also be responsible for maintaining a correspondence between
virtual Linux interrupt values and MSI values.
Software specific to the PCI MSI capable "Northbridge", will then
route general MSI interrupt events to some PCI subsystem helper
functions to verify which MSI has occurred and thus which Linux
virtual interrupt.
Perhaps request_irq() just needs to be explicitly abstracted if
an unsigned int is not sufficient for the entire message space or
if we want messages unique only on a per-space basis i.e. PCI MSIs
can be dups of RapidIO MSIs, etc.
> Oh, and don't make this too PCI-specific -- native PARISC interrupts
> are MSI and you can see how handled it in arch/parisc/kernel/irq.c.
FWIW, another interconnect that natively uses MSI is RapidIO. It's
all in-band doorbell messages, no out-of-band discrete interrupts like
PCI.
Regards,
--
Matt Porter
mporter@kernel.crashing.org
next prev parent reply other threads:[~2003-05-12 17:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-12 16:32 Jeff Garzik
2003-05-12 16:53 ` Matthew Wilcox
2003-05-12 17:20 ` David S. Miller
2003-05-12 18:54 ` Mika Penttilä
2003-05-12 17:43 ` Matt Porter [this message]
2003-05-12 18:20 ` Matthew Wilcox
2003-05-12 18:48 ` Matt Porter
2003-05-13 11:21 ` Ivan Kokshaysky
2003-05-12 17:26 Chuck Ebbert
2003-05-12 17:53 Nakajima, Jun
2003-05-12 18:26 Nakajima, Jun
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=20030512104300.A23510@home.com \
--to=mporter@kernel.crashing.org \
--cc=davem@redhat.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@debian.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
all inboxes | Powered by JetHome®