On 12/01/2022 09:37, maobibo wrote:
Isn't this part already handled by the code in hw/pci/pci.c when the IRQ is
asserted, for example pci_change_irq_level()?
We design a different rule for the pcie devices connect to the root bridge,
assign more irqs to these devices.
For the pci device connect to a pcie-to-pci bridge use the common
pci_swizzle_map_irq_fn to map irq.
I'm less familiar with PCIe but shouldn't the interrupt mapping for devices
connected via a pcie-to-pci bridge be handled by the bridge in this case? Have
a look at pci_bridge_map_irq() to see how this is used. I'd expect the
pcie-to-pci bridge to map the PCI irq to your host controller irq first before
calling pci_ls7a_map_irq(), which I think then becomes just a simple call to
pci_swizzle_map_irq_fn()?
Oh, we will remove these lines. Our original thoughts is that irq-lines of
root bridge is connected with irq controller, so root bridge can have more than
4 irq-lines, non root-bridge has 4 irq-lines at most.
From the code it is only treated as pcie root bridge, and its parent_dev is NULL
always. and we can simply add these sentences such as:
/* pci device start from irq 80 */
offset = PCH_PIC_IRQ_OFFSET + LS7A_DEVICE_IRQS;
irq = offset + ((PCI_SLOT(d->devfn) * 4 + irq_num)) % LS7A_PCI_IRQS;
return irq;
Right, that makes more sense to me. Generally root bridges are different enough from
downstream bridges to be modelled as a separate device (often with a slightly
different product id), so if you can remove the parent_dev check and use the above
that works for me.
ATB,
Mark.
