| Message ID | alpine.DEB.2.21.2107171813230.9461@angie.orcam.me.uk |
|---|---|
| Headers | show |
| Series | x86: PIRQ/ELCR-related fixes and updates | expand |
On Tue, Jul 20, 2021 at 05:27:43AM +0200, Maciej W. Rozycki wrote: > 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. Looks nicely done but I have no ability to review or test, so I assume the x86 folks will take care of this. Bjorn
On Tue, Jul 20 2021 at 19:12, Bjorn Helgaas wrote: > On Tue, Jul 20, 2021 at 05:27:43AM +0200, Maciej W. Rozycki wrote: >> -- 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. > > Looks nicely done but I have no ability to review or test, so I assume > the x86 folks will take care of this. I can review it and pick it up, but for testing I have to rely on the reporter/submitters. Thanks, tglx
Hello Maciej, 20.07.2021 6:27, Maciej W. Rozycki: [...] > 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. Here is a new log with 1/6 and 2/6 applied: https://pastebin.com/0MgXAGtG It looks like something went a bit unexpected ("runtime IRQ mapping not provided by arch"). Thank you, Regards, Nikolai
Hi Nikolai, > > 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. > > Here is a new log with 1/6 and 2/6 applied: > > https://pastebin.com/0MgXAGtG > > It looks like something went a bit unexpected ("runtime IRQ mapping not > provided by arch"). Offhand it looks like your system does not supply a PIRQ table, not at least at the usual locations we look through. The presence of the table is reported like: PCI: IRQ init PCI: Interrupt Routing Table found at 0xfde10 [...] PCI: IRQ fixup while your system says: PCI: IRQ init PCI: IRQ fixup If you have a look through /dev/mem and see if there's a "$PIR" signature somewhere (though not a Linux kernel area of course), then we may know for sure. I'm a little busy at the moment with other stuff and may not be able to look into it properly right now. There may be no solution, not at least an easy one. A DMI quirk is not possible, because: DMI not present or invalid. There is a PCI BIOS: PCI: PCI BIOS revision 2.10 entry at 0xf6f41, last bus=0 however, so CONFIG_PCI_BIOS just might work. Please try that too, by choosing CONFIG_PCI_GOANY or CONFIG_PCI_GOBIOS (it may break things horribly though I imagine). Maciej