[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2107171813230.9461@angie.orcam.me.uk>
Date: Tue, 20 Jul 2021 05:27:43 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Nikolai Zhubr <zhubr.2@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>
cc: x86@...nel.org, linux-pci@...r.kernel.org,
linux-pm@...r.kernel.org, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: [PATCH 0/6] x86: PIRQ/ELCR-related fixes and updates
Hi,
In the course of adding PIRQ routing support for Nikolai's FinALi system
I realised we need to have some infrastructure for the indirectly accessed
configuration space implemented by some chipsets as well as Cyrix CPUs and
also included with the Intel MP spec for the IMCR register via port I/O
space locations 0x22/0x23. With that in place I implemented PIRQ support
for the Intel PCEB/ESC combined EISA southbridge using the same scheme to
access the relevant registers and for the final remaining Intel chipset of
the era, that is the i420EX.
While at it I chose to rewrite ELCR register accesses to avoid using
magic numbers scattered across our code and use proper macros like with
the remaining PIC registers, and while at it again I noticed and fixed a
number of typos: s/ECLR/ELCR/.
Since there are mechanical dependencies between the patches (except for
typo fixes) I chose to send them as a series rather than individually,
though 3/6 depends on: <https://lore.kernel.org/patchwork/patch/1452772/>
necessarily as well, the fate of which is currently unclear to me.
See individual change descriptions for details.
Nikolai: for your system only 1/6 and 2/6 are required, though you are
free to experiment with all the patches. Mind that 3/6 mechanically
depends on the earlier change for the SIO PIRQ router referred above. In
any case please use the debug patch for PCI code as well as the earlier
patches for your other system and send the resulting bootstrap log for
confirmation.
Ideally this would be verified with PCI interrupt sharing, but for that
you'd have to track down one or more multifunction option cards (USB 2.0
interfaces with legacy 1.1 functions or serial/parallel multi-I/O cards
are good candidates, but of course there are more) or option devices with
PCI-to-PCI bridges, and then actually use some of these devices as well.
Any interrupt sharing will be reported, e.g.:
pci 0000:00:07.0: SIO/PIIX/ICH IRQ router [8086:7000]
pci 0000:00:11.0: PCI INT A -> PIRQ 63, mask deb8, excl 0c20
pci 0000:00:11.0: PCI INT A -> newirq 0
PCI: setting IRQ 11 as level-triggered
pci 0000:00:11.0: found PCI INT A -> IRQ 11
pci 0000:00:11.0: sharing IRQ 11 with 0000:00:07.2
pci 0000:02:00.0: using bridge 0000:00:11.0 INT A to get INT A
pci 0000:00:11.0: sharing IRQ 11 with 0000:02:00.0
pci 0000:02:01.0: using bridge 0000:00:11.0 INT B to get INT A
pci 0000:02:02.0: using bridge 0000:00:11.0 INT C to get INT A
pci 0000:03:00.0: using bridge 0000:00:11.0 INT A to get INT A
pci 0000:00:11.0: sharing IRQ 11 with 0000:03:00.0
pci 0000:04:00.0: using bridge 0000:00:11.0 INT B to get INT A
pci 0000:04:00.3: using bridge 0000:00:11.0 INT A to get INT D
pci 0000:00:11.0: sharing IRQ 11 with 0000:04:00.3
pci 0000:06:05.0: using bridge 0000:00:11.0 INT D to get INT A
pci 0000:06:08.0: using bridge 0000:00:11.0 INT C to get INT A
pci 0000:06:08.1: using bridge 0000:00:11.0 INT D to get INT B
pci 0000:06:08.2: using bridge 0000:00:11.0 INT A to get INT C
pci 0000:00:11.0: sharing IRQ 11 with 0000:06:08.2
-- a lot of sharing and swizzling here. :) You'd most definitely need:
<https://lore.kernel.org/patchwork/patch/1454747/> for that though, as I
can't imagine PCI BIOS 2.1 PIRQ routers to commonly enumerate devices
behind PCI-to-PCI bridges, given that they fail to cope with more complex
bus topologies created by option devices in the first place.
Maciej
Powered by blists - more mailing lists