From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Udo van den Heuvel <udovdh@xs4all.nl>, linux-kernel@vger.kernel.org
Subject: Re: PCI riser cards and PCI irq routing, etc
Date: Mon, 19 Feb 2007 10:03:16 -0500 [thread overview]
Message-ID: <20070219150316.GP7582@csclub.uwaterloo.ca> (raw)
In-Reply-To: <m3ejon8afh.fsf@maximus.localdomain>
On Sun, Feb 18, 2007 at 09:42:26PM +0100, Krzysztof Halasa wrote:
> 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.
The PCI spec doesn't require 4 seperate interrupts. They certainly can
all be the same. I do believe it does require the rotation method on
anything using PCI bridges and such if you want your card to work in PCI
compliant systems since that is how they will assume the lines are
routed and hence will assume that is how to set the interrupts. If you
make a mainboard on the other hand you can do whatever you want since
you get to design the firmware that assigns the interrupts.
> Anyway, something has to know how the IRQs are routed. BIOS, other
> firmware, Linux.
>
> Actually it has to be wired consistently with the BIOS (which is
> probably consistent with chipset manufacturer's instructions).
Depends if the riser card is specific to that system, or if it is
supposed to be a generic PCI card.
> 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).
Well dedicated hardware would be different. Of course if it is
dedicated the BIOS better do the right thing when configuring it.
> Actually I think (would have to check the specs for sure) every
> subdevice (function) may use just one interrupt line.
It may. But using just INTB and INTD on a card is not allowed by the
spec as far as I understand it.
> 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.
Sure. But if you have a PCI to PCI bridge on a card, then you only get
4 interrupt lines into the card, and you have to distribute them by the
spec to the chips behind the bridge if you want the system to know how
the interrupts should be used (although I guess a driver could do its
own thing if it really wanted to).
> Correct. This scheme assumes at most 4 single-function devices
> on the bus, otherwise INTs are shared.
It does help make sure that if you have 8 devices, each IRQ is used by
only two devices, so the interrupt handler doesn't have too many devices
to check when an interrupt occours.
--
Len Sorensen
next prev parent reply other threads:[~2007-02-19 15:03 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
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 [this message]
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=20070219150316.GP7582@csclub.uwaterloo.ca \
--to=lsorense@csclub.uwaterloo.ca \
--cc=khc@pm.waw.pl \
--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®