cvs commit: src/sys/dev/acpica acpi_pci_link.c

[Nate Lawson]

M. Warner Losh wrote:
> In message: <4114681D.5020902 at root.org>
>             Nate Lawson <nate at root.org> writes:
> : John Baldwin wrote:
> : > On Friday 06 August 2004 12:50 am, Nate Lawson wrote:
> : > 
> : >>njl         2004-08-06 04:50:56 UTC
> : >>
> : >>  FreeBSD src repository
> : >>
> : >>  Modified files:
> : >>    sys/dev/acpica       acpi_pci_link.c
> : >>  Log:
> : >>  Refine updates to PCI irq routing.  Check _STA and _CRS but only print a
> : >>  message if they are incorrect.  Also, remove the hack of allowing the
> : >>  initial irq setting to not be in _PRS.  As before, the old behavior can
> : >>be regained by defining ACPI_OLD_PCI_LINK.
> : > 
> : > 
> : > Note that I had to back out this removal of the initial IRQ hack because it 
> : > broke things for many people.  The problem is that the current link code 
> : > doesn't do a good job of picking virgin IRQs.
> : > 
> : 
> : I plan to take this to the logical conclusion.  I agree you were on the 
> : right track but didn't go far enough.  :)  I'll send patches in a few days.
> 
> I know that Linux uses (used) a system where it would assign weights
> to the interrupts.  It then would route to the least weighted
> interrupt possible, and then add some factor to its weight so that it
> was less likely to be picked for the next interrupt.  Don't know how
> well that scales, esp for SMP boxes with ioapic.  The initial weights,
> however, heavily biased against the interrupts used by the standard
> set of PC-AT devices: 3 (sio), 4 (sio), 6 (fdc), 7 (ppc), 12 (psm) and
> ata (14, 15).  There was also a mask of invalid IRQs.

We do that too although the algorithm can use improvement (see 
acpi_pci_link.c).  The problem I'm fixing is that we have parallel code 
in acpi_pcib_route and acpi_pci_link that each does half the problem 
well but don't work properly together.  The acpi_pcib_route code does 
well at handling the _PRT but fails utterly at doing a good job of 
routing an unrouted interrupt (it just picks the first one, which is 
often 3).  The acpi_pci_link code has lots of heuristics for balancing 
interrupts and programming links but fails utterly at communicating that 
to the acpi_pcib_route code (it depends on _CRS being correct, which is 
too much to ask of BIOS authors).  The end result is that things really 
only work well when the BIOS initializes the links for us.  Luckily, 
that is often the case.

> This degrated to a round robin assignment of interrupts that weren't
> heavily weighted against.  This is generically fair, but might not be
> optimal for a given system (since it might round robin the two biggest
> interrupt sources together)...

Yes, acpi_pci_link does this.  My work is to join the two, allowing them 
to communicate properly and eliminate duplicate code (that is not quite 
right).  The longer term work, which jhb@ started, is to make pci links 
proper devices, standardize APIs, clean up acpi_pci_link, etc.

-- 
Nate