Re: Still IRQ routing problems with bridged devices.

On 02-Jan-2004 Bernd Walter wrote:
> On Fri, Jan 02, 2004 at 04:30:44PM -0500, John Baldwin wrote:
>> 
>> On 02-Jan-2004 Bernd Walter wrote:
>> > On Fri, Jan 02, 2004 at 02:19:53PM -0500, John Baldwin wrote:
>> >> On 01-Jan-2004 Bernd Walter wrote:
>> >> > On Thu, Jan 01, 2004 at 10:12:23AM -0700, M. Warner Losh wrote:
>> >> >> In message: <20040101155100.GF11668_at_cicely12.cicely.de>
>> > I have no clue about $PIR and therefor have no idea where irq4 comes
>> > from - any pointer to $PIR documents are welcome.
>> 
>> Erm, according to the PCI spec, the devices behind the bridges on the
>> add-in cards will swizzle their interrupts.  Thus, device 8.0 will
>> use INTA on the add-in card's connect, 9.0 will use INTB for its
>> INTA, etc.  We use the $PIR to then figure out what IRQ to use for
>> INT[ABCD] on that slot as appropriate.  Thus, it would work something
>> like this:
>> 
>>  1) device 1.8.0 wants to route INTA so it asks the bridge for the IRQ
>>  2) the bridges translates that into INTA on itself, and asks its parent
>>     for a route to INTA at its slot (say 0.2.0).
> 
> Yes - I know how PCI bridge routing works.
> What I don't know is the x86 sepcific evilness.
> 
>>  3) the host bridge lookes up 0.2.0 INTA in the $PIR, chooses an IRQ from
>>     the possible list (defaults to just using first IRQ) and returns it.
>>     This step should be skipping IRQ 4 adn using IRQ 10 or 11 instead
> 
> That's the interesting part.
> What exactly is in the $PIR table?

The $PIR (you can see it in boot -v) lists for a number of bus/device/pin
combinations what link is used (each link represents a programmable pin
on the interrupt router for our purposes) and what possible interrupts
that link can use.

> Fact is that the 4 PCI connectors share the same intlines wired in
> different INTA-D order which is board specific.
> The intlines are setup by the BIOS to 5, 10, 11 and 12.
> Now FreeBSD has found out that it needs 0.2.0 INTA for the bridged device
> 1.8.0 INTA.
> It now incorrectly selects IRQ4 for 0.2.0 INTA, which is already
> in use for a ISA device by an PnP On-Board component.

Yes, our current algorithm for choosing which interrupt to use if we
don't see one set by the BIOS already is incredibly dumb, which is
what I said earlier. :)

> And I don't see the point why this is not a problem for non bridged
> devices, which would also require an IRQ for 0.2.0 INTA.

If the BIOS has already set an IRQ, we use what the BIOS says.
If the BIOS has already set an IRQ for another device using the
same link, we use that same IRQ.  The problem case is when the
BIOS has not set a device yet for another device with the same
link.  Then the "dumb algorithm" kicks in.

-- 

John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/