From: Jesse Barnes <jbarnes@engr.sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: PCI Express
Date: Wed, 09 Mar 2005 00:02:06 +0000 [thread overview]
Message-ID: <200503081602.07221.jbarnes@engr.sgi.com> (raw)
In-Reply-To: <4228F250.7C5E2E3C@sgi.com>
On Tuesday, March 8, 2005 3:48 pm, Colin Ngam wrote:
> Well, unfortunately, we do not send IPI by using the Processor Interrupt
> Block. We actually
> target a Special Altix Chipset "IPI Interrupt" register that ends up
> generating an IPI. That is why, we
> have Platform Specific "send ipi" calls on ia64:
>
> platform_send_ipi()
> File Line
> 0 machvec.h 113 #define platform_send_ipi ia64_mv.send_ipi
> 1 machvec.h 282 #define platform_send_ipi ia64_send_ipi
> 2 machvec_sn2.h 86 #define platform_send_ipi sn2_send_IPI
> 3 machvec.h 95 #define platform_send_ipi ia64_mv.send_ipi
> 4 machvec.h 255 #define platform_send_ipi ia64_send_ipi
> 5 machvec_sn2.h 83 #define platform_send_ipi sn2_send_IPI
>
> I do not know why we do not use the Processor Interrupt Block, but I will
> find out. But this does
> not mean that we cannot use the PIB for MSI. Ofcourse, it may not be
> relocated at
> 0x0000 0000 FEE0 0000.
That's beside the point though--MSIs don't use IPIs, they just use the
processor interrupt block, which is also used by IPIs (on non-sn2 platforms).
If the processor interrupt block works for us (pretty sure it does) MSIs
targetted there should also work. The problem for us is if a processor tries
to IPI a processor on a different node with the processor interrupt block,
which I don't think MSIs will try to do.
Jesse
next prev parent reply other threads:[~2005-03-09 0:02 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
2005-03-08 19:29 ` Nguyen, Tom L
2005-03-08 23:48 ` Colin Ngam
2005-03-09 0:02 ` Jesse Barnes [this message]
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=200503081602.07221.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