From: Jesse Barnes <jbarnes@engr.sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: PCI Express
Date: Tue, 08 Mar 2005 16:45:49 +0000 [thread overview]
Message-ID: <200503080845.50155.jbarnes@engr.sgi.com> (raw)
In-Reply-To: <4228F250.7C5E2E3C@sgi.com>
On Monday, March 7, 2005 8:40 pm, Colin Ngam wrote:
> It's been a long time since we tested MSI/MSIX on our Altix boxes. It has
> been longer since I looked at the code. It works and we are looking
> forward to hooking them up with the current Infrastructure available on
> ia64 - pci_enable|disable_msi().
>
> On Altix systems, we have a set of "Interrupt Registers" in Memory Address
> Space that is initialized to target specific CPUs. The way we initialize a
> card's MSI is:
>
> 1. The Target Address is One of these "Interrupt Registers"
> 2. The Data Payload is the IRQ plus some special Altix bits.
>
> This memory write causes the "Interrupt Chipset" to generate a LINTR
> message to the configured targeted cpu with the IRQ. Ofcourse, these
> registers are Altix Platform specific. Moreover, we have chunks of these
> registers all over the place.
That's one way to do it, but is obviously very Altix specific.
> Is there a more direct mechanism to generate an interrupt(LINTR Message) to
> a Processor? 1 of the Special bits that I mentioned in Item 2 above causes
> our hardware to flush all posted DMA buffers before allowing the LINTR
> Message to be generated to the cpu.
Yes, see Grant's earlier message about the processor interrupt block. If we
target MSIs at that, they'll behave the same way as IPIs, which are already
platform independent (i.e. they work on Altix, zx1, tiger, etc.) since the
processor interrupt block is builtin to the CPU. See Section 5.8.4 of Vol. 2
of the Itanium Arch. Software Developer's Manual (the blue books).
Jesse
next prev parent reply other threads:[~2005-03-08 16:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-04 23:42 PCI Express Colin Ngam
2005-03-07 16:48 ` Grant Grundler
2005-03-07 16:50 ` Matthew Wilcox
2005-03-07 17:02 ` Mark Maule
2005-03-07 17:21 ` Matthew Wilcox
2005-03-07 20:40 ` Colin Ngam
2005-03-07 23:03 ` Nguyen, Tom L
2005-03-07 23:11 ` Jesse Barnes
2005-03-07 23:31 ` Grant Grundler
2005-03-07 23:32 ` Nguyen, Tom L
2005-03-07 23:36 ` Grant Grundler
2005-03-07 23:40 ` Jesse Barnes
2005-03-07 23:50 ` Grant Grundler
2005-03-08 4:40 ` Colin Ngam
2005-03-08 16:45 ` Jesse Barnes [this message]
2005-03-08 19:29 ` Nguyen, Tom L
2005-03-08 23:48 ` Colin Ngam
2005-03-09 0:02 ` Jesse Barnes
2005-03-09 0:13 ` Colin Ngam
2005-03-09 1:29 ` Colin Ngam
2005-03-09 1:29 ` Jesse Barnes
2005-03-09 1:35 ` Colin Ngam
2005-03-09 3:04 ` Grant Grundler
2005-03-09 15:45 ` Colin Ngam
2005-03-09 16:35 ` Nguyen, Tom L
2005-03-09 17:33 ` Grant Grundler
2005-03-09 17:42 ` Colin Ngam
2005-03-09 17:56 ` Grant Grundler
2005-03-09 18:12 ` Colin Ngam
2005-03-09 18:48 ` Grant Grundler
2005-03-09 19:43 ` Nguyen, Tom L
2005-03-09 21:44 ` Colin Ngam
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=200503080845.50155.jbarnes@engr.sgi.com \
--to=jbarnes@engr.sgi.com \
--cc=linux-ia64@vger.kernel.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