LS1043A MSI interrupts

[Eco56]

Dear Sirs,
I am developing a bare metal PCIe Controller (RC) driver for LS1043A, using a LS1043ARDB board.
I successfully:
- setup all outbound ATUs programming (using LS1043A Linux device tree addresses for system and PCIe addresses and limits).
- discover PCIe bus endpoint and setup them (BARs, etc).
- setup GIC.
- test endpoint legacy interrupts.

Now, I am stuck on MSI interrupts. I am using LS1043A PCIe controller #3 (@ 0x3600000h), and an AX99100 serial/parallel device or an I350 ethernet endpoint, both supporting MSI.

I setup all MSI capability registers on endpoints, and attempted to deliver the MSI interrupt in two different ways:
A) without any inbound ATU, writing in the endpoint MSI address register the address of the SCFG_G2MSIIR register (0x1573000).
B) with an inbound ATU, writing in the endpoint MSI address register the PCIe bus address that the inbound ATU maps to 0x1573000 on the system bus.

In both cases, no interrupt is delivered to GIC. If I write by CPU to the SCFG_G2MSIIR (0x1573000) I see the proper interrupt (192,187,188,or 189) be
delivered depending on the data value I write (0, 1, 2 or 3); therefore, I assume my GIC is properly configured and SCFG is working.

What am I missing to have working MSI interrupts from endpoints?

Best regards
Eco

[cizr]

Dear Sirs,

I'm facing the same problem using the LS1043ARDB, and I believe I’m still missing something on the RC side.

I’m testing with PCIe controller #2 (same behavior observed on controller #3). For controller #2 I’m using SCFG_G2MSIIR = 0x1572000.

First of all, if I manually write from the CPU to 0x1572000, I correctly receive the MSI interrupt on the GIC, so the SCFG and GIC configuration look fine, as reported in eco56.

Also, I am enabling No‑Snoop = 1 and the coherency mapping, as described in the LS1043A documentation.

When I program the i350 endpoint to generate MSI:

• If I don’t configure any inbound iATU, as soon as the device triggers MSI I receive interrupt 160 (PCIe config/error interrupt).
  This makes me think the MSI Memory Write TLP is reaching the RC, but the RC is not able to translate it properly. (if I use legacy interrupt, it trigger the proper legacy interrupt)
• If I configure an inbound iATU, the config/error interrupt disappears, but I still don’t receive any MSI on the GIC.

This is the inbound iATU configuration:

    writel(0x80000000, pcie_rc->dbi + 0x900);  

    writel(0x00000000, pcie_rc->dbi + 0x904);  

    writel(0x01570000, pcie_rc->dbi + 0x90C);  

    writel(0x00000000, pcie_rc->dbi + 0x910);

    writel(0x01573FFF, pcie_rc->dbi + 0x914);

    writel(0x01570000, pcie_rc->dbi + 0x918);  

    writel(0x00000000, pcie_rc->dbi + 0x91C);  

    writel(0x80000000, pcie_rc->dbi + 0x908);

With this configuration, I’m defining an inbound memory window that maps the PCIe address range 0x01570000 – 0x01573FFF into the same range on the system bus, so that inbound PCIe Memory Write transactions targeting 0x1572000 (SCFG_G2MSIIR for controller #2) should be translated and forwarded to the SCFG block.

With this inbound window enabled, I no longer see the PCIe error interrupt, which seems to confirm that the inbound MSI write is now accepted by the RC. However, I still do not see any MSI interrupt being delivered to the GIC when the endpoint generates MSI.

Could you please confirm if this setup is correct, or if there is any additional RC‑side configuration required to get MSI delivered to the GIC?

Riccardo

[LFGP]

dear Eco56,

For MSI interrupts on LS1043A PCIe controller, the proper configuration requires:

- The MSI address register in your endpoint devices should point to SCFG_G2MSIIR register (0x1573000) as you've attempted.
- Ensure the proper GIC interrupt line is configured for the corresponding PCIe controller #3 (interrupt 192, 187, 188, or 189 as you noted).
- The PCIe controller must have MSI capability enabled in its configuration space.
- Verify that the inbound ATU window is correctly mapping the PCIe address space to the system memory where SCFG_G2MSIIR (0x1573000) is located.
- Ensure the ATU window size is sufficient and properly aligned.
- Check that transaction attributes are properly configured (No Snoop and Relaxed Ordering should be set to 0).

- For your direct approach without inbound ATU:
Since you can write directly to SCFG_G2MSIIR and see interrupts delivered to GIC, your GIC configuration appears correct.
Try enabling the Bus Master capability for your endpoints to ensure they can initiate memory write transactions. Also verify that the endpoints' MSI capability registers are properly configured, particularly the MSI Enable bit.
BR
LFGP