> - pcie_portdrv_probe() will be called for every BRIDGE class PCI device. > P2020 PCIe is a PCI-PCI BRIDGE class so no problem here. > - The code will continue to check that we have PCI_CAP_ID_EXP capability, > which we have and continue to pcie_port_device_register(). > - Now ,the function pcie_port_device_register() will FAIL. It will fail > because it will call assign_interrupt_mode(), return with PCIE_PORT_NO_IRQ, > and giveup with a reasonable remark in the code > "/* > * Don't use service devices that require interrupts if there is > * no way to generate them. > */" > > So now the question is why calling assign_interrupt_mode() with the P2020 > PCIe ROOT device return empty? Well... > - First assign_interrupt_mode() will test for PCIE_PORT_MSIX_MODE. Freescale > PCIe does not support this... > - Second attampt is made to discover PCIE_PORT_MSI_MODE, which Freescale > should support but the PCIe PCI_CAP_ID_MSI capability is published on the > device side of the bridge and NOT on the PCIe ROOT device, which is the one > probed and thus fails. > - Last it attempts to look at "dev->pin" in order to set > PCIE_PORT_INTx_MODE. On top of being the less recommended way (the old way), > The Freescale PCIE ROOT device pin is not set anywhere. > > Failing all those the probe fails and the AER service is not activated for > the PCIE device.
So the question boils down to how does the bridge generate the AER interrupts. This should be documented in the FSL docs no ? The MSI in the child/device should be unrelated (it's your device MSI) no ? So the question is where's the missing interrupt. If it's a SoC interrupt, coming from the device-tree, then perhaps the generic AER code should be extended to recognize those. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
