mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: Udo van den Heuvel <udovdh@xs4all.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PCI riser cards and PCI irq routing, etc
Date: Sun, 18 Feb 2007 10:54:45 -0500	[thread overview]
Message-ID: <20070218155445.GV7584@csclub.uwaterloo.ca> (raw)
In-Reply-To: <45D85DA1.7090502@xs4all.nl>

On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote:
> Is there some howto information available about using PCI riser cards
> (with multiple PCI slots) under Linux?
> Several incarnations exist of PCI riser cards with two PCI slots where
> the Device Number of one slot can be changed.
> How, based on what information, does Linux assign an IRQ to each card,
> plugged into the riser?
> How can one tweak/influence the irq routing?
> How can I make a dual riser card work so that both cards have a working
> interrupt?
> Or if stuff should work all by itself, what could be wrong?

The PCI specifications cover how pci to pci bridges should work.

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

The same rules apply behind a PCI bridge, so whatever INTA is on the
slot with the pci bridge chip, should make to INTA on slots 0, 4, 8, etc
behind the bridge, while INTB is seen as INTA on slots 1, 5, 9, etc.

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.  On ARM for example, the kernel takes care of assigning this
(or it least it should).  I have seen pci interrupt swizzle routines in
the kernel code for an arm system which went through, looking for
devices, and assigning IRQs based on their slot number, and when it
found a bridge it would do a mapping past the bridge and continue
assigning interrupts to devices behind the bridge.

So as long as the riser board is wired according to the PCI bridge
rules, then interrupts assignment should simply work.  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.

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.  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.  On some systems some of the 4 PCI interrupts may in fact get
mapped to the same interrupts if not enough are available (for example a
system I work with only has two PCI interrupts available, so PCI INTA
and C are the same interrupt line, and INTB and D are the same, but the
system is still wired as if there were 4 interrupts, and the BIOS
assigns the interrupts properly based on that, but using IRQ 11 for A
and C and IRQ 10 for B and D.)

--
Len Sorensen

  reply	other threads:[~2007-02-18 15:54 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-18 14:07 Udo van den Heuvel
2007-02-18 15:54 ` Lennart Sorensen [this message]
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
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=20070218155445.GV7584@csclub.uwaterloo.ca \
    --to=lsorense@csclub.uwaterloo.ca \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®