From: Krzysztof Halasa <khc@pm.waw.pl>
To: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
Cc: Udo van den Heuvel <udovdh@xs4all.nl>, linux-kernel@vger.kernel.org
Subject: Re: PCI riser cards and PCI irq routing, etc
Date: Sun, 18 Feb 2007 21:42:26 +0100 [thread overview]
Message-ID: <m3ejon8afh.fsf@maximus.localdomain> (raw)
In-Reply-To: <20070218155445.GV7584@csclub.uwaterloo.ca> (Lennart Sorensen's message of "Sun, 18 Feb 2007 10:54:45 -0500")
lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:
> My understanding (which is better of verified against the specs) is:
>
> PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So
> slot 0, 4, 8, etc see INTA->realINTA, INTB->realINTB. INTC->realINTC,
> INTD->realINTD
> slot 1, 5, 9, etc see INTA->realINTB, INTB->realINTC. INTC->realINTD,
> INTD->realINTA
> slot 2, 6, 10, etc see INTA->realINTC, INTB->realINTD. INTC->realINTA,
> INTD->realINTB
> slot 3, 7, 11, etc see INTA->realINTD, INTB->realINTA. INTC->realINTB,
> INTD->realINTC
This is common and suggested practice but the PCI specs don't require
it. There is no rule - you can, for example, have all INT lines
connected to a single CPU IRQ input.
> On a PC, the BIOS is supposed to assign interrupts to devices based on
> those rules, since that is how the hardware must be done according to
> the PCI specifications. On other platforms the firmware may or may not
> handle it.
Anyway, something has to know how the IRQs are routed. BIOS, other
firmware, Linux.
> So as long as the riser board is wired according to the PCI bridge
> rules,
Actually it has to be wired consistently with the BIOS (which is
probably consistent with chipset manufacturer's instructions).
> Of course if the
> riser card is NOT a proper pci bridge, but rather some weird device,
> well then it probably isn't even PCI complient and who knows how it
> shold be handled.
Usually they are just bus splitters, they route IRQs and IDSELs
(and maybe JTAG) as required by the BIOS, all others pins are
connected 1:1.
I.e., they are completely transparent, generally comply to PCI specs
and are dedicated to a specific motherboard(s).
> Interrupts for PCI are assigned based on the 4 shared interrupts line on
> PCI, not really per device. A PCI device may use up to 4 interrupts if
> it wants to, and is supposed to always use interrupt A (as seen from
> it's slot) as the first interrupt.
Actually I think (would have to check the specs for sure) every
subdevice (function) may use just one interrupt line.
This rotating INTx scheme is common because it's cheap. There are
systems which support more than 4 shared INTs per bus, for example
you can have different sets of 4 INTx lines for every PCI slot, even
if all slots are on the same PCI bus.
> The rotating assignment of the 4
> interrupts to the slots are supposed to help balance the distribution of
> the interrupts between devices in the system, so that although they are
> shared interrupts, as few devices as possible get assigned to each
> interrupt.
Correct. This scheme assumes at most 4 single-function devices
on the bus, otherwise INTs are shared.
--
Krzysztof Halasa
next prev parent reply other threads:[~2007-02-18 20:42 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-18 14:07 PCI riser cards and PCI irq routing, etc Udo van den Heuvel
2007-02-18 15:54 ` Lennart Sorensen
2007-02-18 16:15 ` Udo van den Heuvel
2007-02-18 19:39 ` Lennart Sorensen
2007-02-19 1:50 ` Alistair John Strachan
2007-02-19 4:04 ` Udo van den Heuvel
2007-02-19 15:17 ` Lennart Sorensen
2007-02-19 15:43 ` Udo van den Heuvel
2007-02-19 17:13 ` Lennart Sorensen
2007-02-19 15:09 ` Udo van den Heuvel
2007-02-19 20:37 ` Krzysztof Halasa
2007-02-20 4:17 ` Udo van den Heuvel
2007-02-20 14:56 ` Alistair John Strachan
2007-02-20 15:44 ` Udo van den Heuvel
2007-02-20 19:51 ` Alistair John Strachan
2007-02-21 9:24 ` Udo van den Heuvel
2007-02-21 12:24 ` Krzysztof Halasa
2007-02-21 14:59 ` Udo van den Heuvel
2007-02-21 15:12 ` Lennart Sorensen
[not found] ` <m3hctfqjna.fsf@maximus.localdomain>
2007-02-21 22:40 ` Lennart Sorensen
2007-02-21 23:55 ` Alistair John Strachan
2007-02-22 1:19 ` Krzysztof Halasa
2007-02-23 15:45 ` Udo van den Heuvel
2007-02-23 15:54 ` Lennart Sorensen
2007-02-23 17:55 ` Krzysztof Halasa
2007-02-23 18:17 ` Udo van den Heuvel
2007-02-23 19:42 ` Krzysztof Halasa
2007-03-03 14:35 ` Udo van den Heuvel
2007-02-23 18:12 ` Krzysztof Halasa
2007-02-23 18:44 ` Udo van den Heuvel
2007-02-23 20:00 ` Krzysztof Halasa
2007-02-25 15:59 ` Udo van den Heuvel
2007-02-22 1:16 ` Krzysztof Halasa
2007-02-21 18:11 ` Udo van den Heuvel
2007-02-21 19:54 ` Krzysztof Halasa
2007-02-21 20:13 ` Lennart Sorensen
2007-02-21 19:36 ` Krzysztof Halasa
2007-02-21 13:44 ` Lennart Sorensen
2007-02-21 18:55 ` Udo van den Heuvel
2007-02-20 20:47 ` Krzysztof Halasa
2007-02-20 21:51 ` Lennart Sorensen
2007-02-21 0:11 ` Krzysztof Halasa
2007-02-21 13:46 ` Lennart Sorensen
2007-02-20 4:35 ` Udo van den Heuvel
2007-02-21 0:03 ` Krzysztof Halasa
2007-02-18 20:50 ` Krzysztof Halasa
2007-02-18 20:42 ` Krzysztof Halasa [this message]
2007-02-19 15:03 ` Lennart Sorensen
2007-02-19 18:23 ` Krzysztof Halasa
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=m3ejon8afh.fsf@maximus.localdomain \
--to=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=udovdh@xs4all.nl \
/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