[PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts

Bandi, Ravi Kumar ravib at amazon.com
Tue Oct 21 13:55:41 PDT 2025



> On Oct 21, 2025, at 12:10 PM, Bjorn Helgaas <helgaas at kernel.org> wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On Tue, Oct 21, 2025 at 05:46:17PM +0000, Bandi, Ravi Kumar wrote:
>>> On Oct 21, 2025, at 10:23 AM, Bjorn Helgaas <helgaas at kernel.org> wrote:
>>> On Sat, Sep 20, 2025 at 10:52:32PM +0000, Ravi Kumar Bandi wrote:
>>>> The pcie-xilinx-dma-pl driver does not enable INTx interrupts
>>>> after initializing the port, preventing INTx interrupts from
>>>> PCIe endpoints from flowing through the Xilinx XDMA root port
>>>> bridge. This issue affects kernel 6.6.0 and later versions.
>>>> 
>>>> This patch allows INTx interrupts generated by PCIe endpoints
>>>> to flow through the root port. Tested the fix on a board with
>>>> two endpoints generating INTx interrupts. Interrupts are
>>>> properly detected and serviced. The /proc/interrupts output
>>>> shows:
>>>> 
>>>> [...]
>>>> 32:        320          0  pl_dma:RC-Event  16 Level     400000000.axi-pcie, azdrv
>>>> 52:        470          0  pl_dma:RC-Event  16 Level     500000000.axi-pcie, azdrv
>>>> [...]
>>>> 
>>>> Changes since v1::
>>>> - Fixed commit message per reviewer's comments
>>>> 
>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
>>>> Cc: stable at vger.kernel.org
>>>> Signed-off-by: Ravi Kumar Bandi <ravib at amazon.com>
>>> 
>>> Hi Ravi, obviously you tested this, but I don't know how to reconcile
>>> this with Stefan's INTx fix at
>>> https://lore.kernel.org/r/20251021154322.973640-1-stefan.roese@mailbox.org
>>> 
>>> Does Stefan's fix need to be squashed into this patch?
>> 
>> Sure, we can squash Stefan’s fix into this.
> 
> I know we *can* squash them.
> 
> I want to know why things worked for you and Stefan when they
> *weren't* squashed:
> 
>  - Why did INTx work for you even without Stefan's patch.  Did you
>    get INTx interrupts but not the right ones, e.g., did the device
>    signal INTA but it was received as INTB?

I saw that interrupts were being generated by the endpoint device, but I didn’t specifically check if they were correctly translated in the controller. I noticed that the new driver wasn't explicitly enabling the interrupts, so my first approach was to enable them, which helped the interrupts flow through.

> 
>  - Why did Stefan's patch work for him even without your patch.  How
>    could Stefan's INTx work without the CSR writes to enable
>    interrupts?

I'm not entirely sure if there are any other dependencies in the FPGA bitstream. I'll investigate further and get back to you.

> 
>  - Why you mentioned "kernel 6.6.0 and later versions."  8d786149d78c
>    appeared in v6.7, so why would v6.6.0 would be affected?

Apologies for not clearly mentioning the version earlier. This is from the linux-xlnx tree on the xlnx_rebase_v6.6 branch, which includes the new Xilinx root port driver with QDMA support:
https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v6.6_LTS/drivers/pci/controller/pcie-xilinx-dma-pl.c

In earlier versions, the driver was:
https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v6.1_LTS_2023.1_update/drivers/pci/controller/pcie-xdma-pl.c
This older driver had no issues with interrupts.

The new driver introduced in v6.7 and later is a rewrite of the old one, now with QDMA support, which has issues with INTx interrupts.

Thank you.

> 
>>>> +++ b/drivers/pci/controller/pcie-xilinx-dma-pl.c
>>>> @@ -659,6 +659,12 @@ static int xilinx_pl_dma_pcie_setup_irq(struct pl_dma_pcie *port)
>>>>             return err;
>>>>     }
>>>> 
>>>> +     /* Enable interrupts */
>>>> +     pcie_write(port, XILINX_PCIE_DMA_IMR_ALL_MASK,
>>>> +                XILINX_PCIE_DMA_REG_IMR);
>>>> +     pcie_write(port, XILINX_PCIE_DMA_IDRN_MASK,
>>>> +                XILINX_PCIE_DMA_REG_IDRN_MASK);
>>>> +
>>>>     return 0;
>>>> }



More information about the linux-arm-kernel mailing list