On Thu, Sep 12, 2024 at 4:28 PM Tim Harvey <tharvey@xxxxxxxxxxxxx> wrote: > > On Tue, Sep 10, 2024 at 4:04 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > > > On Tue, Sep 10, 2024 at 09:50:02AM -0700, Tim Harvey wrote: > > > On Fri, Sep 6, 2024 at 12:58 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > > > On Fri, Sep 06, 2024 at 12:37:42PM -0700, Tim Harvey wrote: > > > > > ... > > > > > > > > > I have the hardware in hand now as well as the out-of-tree driver > > > > > that's being used. I can say there is nothing wrong here with legacy > > > > > PCI interrupt mapping, if I write a skeleton driver that uses > > > > > pci_resister_driver(struct pci_driver) its probe is called with an > > > > > interrupt and request_irq on that interrupt succeeds just fine. > > > > > > > > > > The issue here is with the vendor's out-of-tree driver which instead > > > > > is using pci_get_device() to scan the bus which returns a struct > > > > > pci_dev * that doesn't have an irq assigned (like what is described > > > > > in > > > > > https://www.kernel.org/doc/html/v5.5/PCI/pci.html#how-to-find-pci-devices-manually). > > > > > When using pci_get_device() when/how does pci_assign_irq() get > > > > > called to assign the irq to the device? > > > > > > > > Hmmm. pci_get_device() is strongly discouraged because it subverts > > > > the driver model (it skips the usual driver probe/claim model so it > > > > allows multiple drivers to operate the device simultaneously which can > > > > obviously cause conflicts), and it doesn't play well with hotplug > > > > (hotplug events automatically cause driver .probe() methods to be > > > > called, but users of pci_get_device() have to roll their own way of > > > > doing this). > > > > > > > > So I'm not aware of a documented/supported way to set up the INTx > > > > interrupts in the pci_get_device() case. > > > > > > Makes sense to me. Perhaps some changes to Documentation/PCI/pci.rst > > > could explain this. > > > > Yeah, that would be a good idea. > > > > > Thanks for the help here, glad to find there is nothing broken here. I > > > think there could have been some confusion by the user here because > > > they were used to x86 assigning irq's without using > > > pci_resister_driver() but they were also using a kernel param of > > > pci=routeirq which looks like its an x86 only temporary workaround > > > that may have made this work on that architecture. > > > > I wondered about "pci=routirq", but I lost the trail and couldn't > > figure out how that would lead to pci_assign_irq() or something > > functionally equivalent. > > > > Hi Bjorn and Frank, > > While switching to pci_resister_driver() resolves the request_irq > issue I find that legacy IRQ's fire on the imx8mm/imx8mp only when the > device is not behind a bridge: > > Again this specific device is a DDK BU-69092S1 which has a TI XIO2001 > PCIe-to-PCI bridge with a PCI device behind it. > > Here is an example of a GW72xx (which has a PI7C9X2G404E 4-port PCIe > switch) with an imx8mm: > root@noble-venice:~# uname -r > 6.6.8-gc6ef8b5e47a0 > root@noble-venice:~# lspci -n > 00:00.0 0604: 16c3:abcd (rev 01) > 01:00.0 0604: 12d8:b404 (rev 01) > 02:01.0 0604: 12d8:b404 (rev 01) > 02:02.0 0604: 12d8:b404 (rev 01) > 02:03.0 0604: 12d8:b404 (rev 01) > 04:00.0 0604: 104c:8240 > 05:00.0 0780: 4ddc:1a00 (rev 10) > 05:01.0 0780: 4ddc:1a00 (rev 10) > 06:00.0 0200: 1055:7430 (rev 11) > root@noble-venice:~# lspci -s 05:00 -vvv | grep Interrupt > Interrupt: pin A routed to IRQ 206 > root@noble-venice:~# grep 206 /proc/interrupts > 206: 0 0 0 0 GICv3 157 Level > PCIe PME > ^^^ makes sense... driver has probed and requested the IRQ but nothing > has made it fire yet > root@noble-venice:~# ./tester > Testing.....Registers Passed test. > Testing.....Ram Passed 1234 test. > Testing.....Ram Passed aaaa test. > Testing.....Ram Passed aa55 test. > Testing.....Ram Passed 55aa test. > Testing.....Ram Passed 5555 test. > Testing.....Ram Passed ffff test. > Testing.....Ram Passed 1111 test. > Testing.....Ram Passed 8888 test. > Testing.....Ram Passed 0000 test. > Testing.....Interrupt Test Failure, NO IRQ!!! > Testing.....Protocol Test RTL Function Failure-> Function not supported. > Testing.....Vector Test RTL Function Failure-> Function not supported. > EXIT: tester > ^^^ this app causes the device to fire an IRQ and verifies its been > caught; fails due to no irq firing > root@noble-venice:~# grep 206 /proc/interrupts > 206: 0 0 0 0 GICv3 157 Level > PCIe PME > ^^^ 0 interrupts > > Here is an example of the same device on a GW71xx (which has no > switch) with an imx8mm: > root@noble-venice:~# uname -r > 6.6.8-gc6ef8b5e47a0 > root@noble-venice:~# lspci -n > 00:00.0 0604: 16c3:abcd (rev 01) > 01:00.0 0604: 104c:8240 > 02:00.0 0780: 4ddc:1a00 (rev 10) > 02:01.0 0780: 4ddc:1a00 (rev 10) > root@noble-venice:~# lspci -s 02:00 -vvv | grep Interrupt > Interrupt: pin A routed to IRQ 204 > root@noble-venice:~# grep 204 /proc/interrupts > 204: 0 0 0 0 GICv3 157 Level > PCIe PME > root@noble-venice:~# ./tester > Testing.....Registers Passed test. > Testing.....Ram Passed 1234 test. > Testing.....Ram Passed aaaa test. > Testing.....Ram Passed aa55 test. > Testing.....Ram Passed 55aa test. > Testing.....Ram Passed 5555 test. > Testing.....Ram Passed ffff test. > Testing.....Ram Passed 1111 test. > Testing.....Ram Passed 8888 test. > Testing.....Ram Passed 0000 test. > Testing.....Interrupt Occurred, Passed test. > Testing.....Protocol Test RTL Function Failure-> Function not supported. > Testing.....Vector Test RTL Function Failure-> Function not supported. > EXIT: tester > root@noble-venice:~# grep 204 /proc/interrupts > 204: 1 0 0 0 GICv3 157 Level > PCIe PME > > I believe this issue is likely the same thing I enquired about over a > year ago [1] showing with an ath9k device which uses legacy IRQ's > which I've also never resolved. > > Any ideas here? > Bjorn and Frank, any ideas here? I neglected to point to the other email which referenced what I believe to be the same issue: https://www.spinics.net/lists/linux-wireless/msg233763.html I believe that legacy interrupts do not work on imx8m{m,p} when behind a bridge. I believe the interrupts are getting swizzled when they should not as it's a PCIe bridge (Int A/B/C/D should be mapped based on dt and thus should not change depending on downstream slot). Best Regards, Tim
