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

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

[Ravi Kumar Bandi]

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@vger.kernel.org
Signed-off-by: Ravi Kumar Bandi <ravib@amazon.com>
---
 drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c
index b037c8f315e4..cc539292d10a 100644
--- a/drivers/pci/controller/pcie-xilinx-dma-pl.c
+++ 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;
 }
 
-- 
2.47.3

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

[Bandi, Ravi Kumar]

Hello Mani, Thippeswamy,

A gentle reminder to review patch v2. Please let me know if you need any additional information. Thanks.

Sincerely,
Ravi

> On Sep 20, 2025, at 3:52 PM, Bandi, Ravi Kumar <ravib@amazon.com> 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@vger.kernel.org
> Signed-off-by: Ravi Kumar Bandi <ravib@amazon.com>
> ---
> drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c
> index b037c8f315e4..cc539292d10a 100644
> --- a/drivers/pci/controller/pcie-xilinx-dma-pl.c
> +++ 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;
> }
> 
> -- 
> 2.47.3
> 

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

[Manivannan Sadhasivam]

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@vger.kernel.org
> Signed-off-by: Ravi Kumar Bandi <ravib@amazon.com>

Thippeswamy, are you fine with this change?

- Mani

> ---
>  drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c
> index b037c8f315e4..cc539292d10a 100644
> --- a/drivers/pci/controller/pcie-xilinx-dma-pl.c
> +++ 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;
>  }
>  
> -- 
> 2.47.3
> 

-- 
மணிவண்ணன் சதாசிவம்

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

[Manivannan Sadhasivam]

On Mon, Sep 29, 2025 at 07:38:01PM +0530, Manivannan Sadhasivam 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@vger.kernel.org
> > Signed-off-by: Ravi Kumar Bandi <ravib@amazon.com>
> 
> Thippeswamy, are you fine with this change?
> 

Since there was no reply for a while and the change looked good to me, I've
merged this patch.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Manivannan Sadhasivam]

On Sat, 20 Sep 2025 22:52:32 +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:
> 
> [...]

Applied, thanks!

[1/1] PCI: xilinx-xdma: Enable INTx interrupts
      commit: c098c13f4365e6750009be4d90dba36fa4a19b4e

Best regards,
-- 
Manivannan Sadhasivam <mani@kernel.org>

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

[Bjorn Helgaas]

[+cc Stefan et al]

On Sun, Oct 19, 2025 at 12:39:25PM +0530, Manivannan Sadhasivam wrote:
> On Sat, 20 Sep 2025 22:52:32 +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:
> > 
> > [...]
> 
> Applied, thanks!
> 
> [1/1] PCI: xilinx-xdma: Enable INTx interrupts
>       commit: c098c13f4365e6750009be4d90dba36fa4a19b4e

Pretty sure we have confirmation that we don't need either this patch
or Stefan's patch, so I removed the pci/controller/xilinx-dma branch.

It was at 2002478e5034 ("PCI: xilinx-xdma: Enable INTx interrupts") in
case we need to resurrect it.

IIUC, Stefan confirmed that he didn't need this patch (Ravi's) [1],
and that after Vivado is fixed to generate the correct interrupt-map,
his patch (Stefan's) won't be needed either [2].

[1] https://lore.kernel.org/r/29bc5e92-04c9-475a-ba3d-a5ea26f1c95a@mailbox.org
[2] https://lore.kernel.org/r/9c7e43c3-24e9-4b08-a6ce-2035b50226f4@mailbox.org

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

[Bandi, Ravi Kumar]

> On Oct 27, 2025, at 4:28 PM, Bjorn Helgaas <helgaas@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.
> 
> 
> 
> [+cc Stefan et al]
> 
> On Sun, Oct 19, 2025 at 12:39:25PM +0530, Manivannan Sadhasivam wrote:
>> On Sat, 20 Sep 2025 22:52:32 +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:
>>> 
>>> [...]
>> 
>> Applied, thanks!
>> 
>> [1/1] PCI: xilinx-xdma: Enable INTx interrupts
>>      commit: c098c13f4365e6750009be4d90dba36fa4a19b4e
> 
> Pretty sure we have confirmation that we don't need either this patch
> or Stefan's patch, so I removed the pci/controller/xilinx-dma branch.
> 
> It was at 2002478e5034 ("PCI: xilinx-xdma: Enable INTx interrupts") in
> case we need to resurrect it.
> 
> IIUC, Stefan confirmed that he didn't need this patch (Ravi's) [1],
> and that after Vivado is fixed to generate the correct interrupt-map,
> his patch (Stefan's) won't be needed either [2].
> 
> [1] https://lore.kernel.org/r/29bc5e92-04c9-475a-ba3d-a5ea26f1c95a@mailbox.org
> [2] https://lore.kernel.org/r/9c7e43c3-24e9-4b08-a6ce-2035b50226f4@mailbox.org

Hello Bjorn, and Mani et al.,

Thank you for taking the time to review the patch and explain the reasoning.

Sincerly,
Ravi

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

[Bjorn Helgaas]

[+cc Stefan, Sean]

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@vger.kernel.org
> Signed-off-by: Ravi Kumar Bandi <ravib@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?

> ---
>  drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c
> index b037c8f315e4..cc539292d10a 100644
> --- a/drivers/pci/controller/pcie-xilinx-dma-pl.c
> +++ 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;
>  }
>  
> -- 
> 2.47.3
> 

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

[Bandi, Ravi Kumar]

> On Oct 21, 2025, at 10:23 AM, Bjorn Helgaas <helgaas@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.
> 
> 
> 
> [+cc Stefan, Sean]
> 
> 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@vger.kernel.org
>> Signed-off-by: Ravi Kumar Bandi <ravib@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?

Hi Bjorn,

Sure, we can squash Stefan’s fix into this.

Thanks
Ravi

> 
>> ---
>> drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>> 
>> diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c
>> index b037c8f315e4..cc539292d10a 100644
>> --- a/drivers/pci/controller/pcie-xilinx-dma-pl.c
>> +++ 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;
>> }
>> 
>> --
>> 2.47.3
>> 

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

[Bjorn Helgaas]

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@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@vger.kernel.org
> >> Signed-off-by: Ravi Kumar Bandi <ravib@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?

  - 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?

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

> >> +++ 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;
> >> }

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

[Bandi, Ravi Kumar]

> On Oct 21, 2025, at 12:10 PM, Bjorn Helgaas <helgaas@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@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@vger.kernel.org
>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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;
>>>> }

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

[Bjorn Helgaas]

On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > 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@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@vger.kernel.org
> >>>> Signed-off-by: Ravi Kumar Bandi <ravib@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.

OK, I'll assume the interrupts happened but the driver might not have
been able to handle them correctly, e.g., it was prepared for INTA but
got INTB or similar.

> >  - 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.

Stefan clarified in a private message that he had applied your patch
first, so this mystery is solved.

> >  - 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.

OK, this sounds like out-of-tree history that is not relevant in the
mainline kernel, so Mani did the right thing in omitting it.

I think the best thing to do is to squash Stefan's patch into this one
so we end up with a single patch that makes INTx work correctly.

Ravi and Stefan, does that seem OK to 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;
> >>>> }
> 

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

[Bandi, Ravi Kumar]

> On Oct 21, 2025, at 2:28 PM, Bjorn Helgaas <helgaas@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 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
>>> 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@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@vger.kernel.org
>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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.
> 
> OK, I'll assume the interrupts happened but the driver might not have
> been able to handle them correctly, e.g., it was prepared for INTA but
> got INTB or similar.
> 
>>> - 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.
> 
> Stefan clarified in a private message that he had applied your patch
> first, so this mystery is solved.

Thanks for confirming.

> 
>>> - 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.
> 
> OK, this sounds like out-of-tree history that is not relevant in the
> mainline kernel, so Mani did the right thing in omitting it.
> 
> I think the best thing to do is to squash Stefan's patch into this one
> so we end up with a single patch that makes INTx work correctly.
> 
> Ravi and Stefan, does that seem OK to you?

Sure, I’m OK, 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;
>>>>>> }
>> 

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

[Stefan Roese]

Hi Bjorn,
Hi Ravi,

On 10/21/25 23:28, Bjorn Helgaas wrote:
> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
>>> 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@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
>>>>>> [...]

First a comment on this IRQ logging:

These lines do NOT refer to the INTx IRQ(s) but the controller internal
"events" (errors etc). Please see this log for INTx on my Versal
platform with pci_irqd_intx_xlate added:

  24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
  25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
  26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
  27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
  28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
  29:          0          0  pl_dma:RC-Event  11 Level     FATAL
  30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
  31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
  32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
  33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
  34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
  35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
  36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
  37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
  38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
  39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1

The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
Event').

More below...

>>>>>>
>>>>>> Changes since v1::
>>>>>> - Fixed commit message per reviewer's comments
>>>>>>
>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
>>>>>> Cc: stable@vger.kernel.org
>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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.
> 
> OK, I'll assume the interrupts happened but the driver might not have
> been able to handle them correctly, e.g., it was prepared for INTA but
> got INTB or similar.
> 
>>>   - 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.
> 
> Stefan clarified in a private message that he had applied your patch
> first, so this mystery is solved.

Yes. I applied Ravi's patch first and still got no INTx delivered
to the nvme driver. That's what me triggered to dig deeper here and
resulted in this v2 patch with pci_irqd_intx_xlate added.

BTW:
I re-tested just now w/o Ravi's patch and the INTx worked. Still I think
Ravi's patch is valid and should be applied...
>>>   - 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.
> 
> OK, this sounds like out-of-tree history that is not relevant in the
> mainline kernel, so Mani did the right thing in omitting it.
> 
> I think the best thing to do is to squash Stefan's patch into this one
> so we end up with a single patch that makes INTx work correctly.
> 
> Ravi and Stefan, does that seem OK to you?

Yes, please either apply both separately or squash them. Whatever you
prefer.

Many thanks,
Stefan
>>>>>> +++ 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;
>>>>>> }
>>

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

[mani]

On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> Hi Bjorn,
> Hi Ravi,
> 
> On 10/21/25 23:28, Bjorn Helgaas wrote:
> > On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > > > 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@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
> > > > > > > [...]
> 
> First a comment on this IRQ logging:
> 
> These lines do NOT refer to the INTx IRQ(s) but the controller internal
> "events" (errors etc). Please see this log for INTx on my Versal
> platform with pci_irqd_intx_xlate added:
> 
>  24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
>  25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
>  26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
>  27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
>  28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
>  29:          0          0  pl_dma:RC-Event  11 Level     FATAL
>  30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
>  31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
>  32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
>  33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
>  34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
>  35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
>  36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
>  37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
>  38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
>  39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> 
> The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
> Event').
> 
> More below...
> 
> > > > > > > 
> > > > > > > Changes since v1::
> > > > > > > - Fixed commit message per reviewer's comments
> > > > > > > 
> > > > > > > Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
> > > > > > > Cc: stable@vger.kernel.org
> > > > > > > Signed-off-by: Ravi Kumar Bandi <ravib@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.
> > 
> > OK, I'll assume the interrupts happened but the driver might not have
> > been able to handle them correctly, e.g., it was prepared for INTA but
> > got INTB or similar.
> > 
> > > >   - 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.
> > 
> > Stefan clarified in a private message that he had applied your patch
> > first, so this mystery is solved.
> 
> Yes. I applied Ravi's patch first and still got no INTx delivered
> to the nvme driver. That's what me triggered to dig deeper here and
> resulted in this v2 patch with pci_irqd_intx_xlate added.
> 
> BTW:
> I re-tested just now w/o Ravi's patch and the INTx worked. Still I think
> Ravi's patch is valid and should be applied...

How come INTx is working without the patch from Ravi which enabled INTx routing
in the controller? Was it enabled by default in the hardware?

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Stefan Roese]

On 10/22/25 11:55, mani@kernel.org wrote:
> On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
>> Hi Bjorn,
>> Hi Ravi,
>>
>> On 10/21/25 23:28, Bjorn Helgaas wrote:
>>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
>>>>> 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@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
>>>>>>>> [...]
>>
>> First a comment on this IRQ logging:
>>
>> These lines do NOT refer to the INTx IRQ(s) but the controller internal
>> "events" (errors etc). Please see this log for INTx on my Versal
>> platform with pci_irqd_intx_xlate added:
>>
>>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
>>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
>>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
>>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
>>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
>>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
>>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
>>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
>>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
>>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
>>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
>>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
>>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
>>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
>>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
>>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
>>
>> The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
>> Event').
>>
>> More below...
>>
>>>>>>>>
>>>>>>>> Changes since v1::
>>>>>>>> - Fixed commit message per reviewer's comments
>>>>>>>>
>>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver")
>>>>>>>> Cc: stable@vger.kernel.org
>>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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.
>>>
>>> OK, I'll assume the interrupts happened but the driver might not have
>>> been able to handle them correctly, e.g., it was prepared for INTA but
>>> got INTB or similar.
>>>
>>>>>    - 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.
>>>
>>> Stefan clarified in a private message that he had applied your patch
>>> first, so this mystery is solved.
>>
>> Yes. I applied Ravi's patch first and still got no INTx delivered
>> to the nvme driver. That's what me triggered to dig deeper here and
>> resulted in this v2 patch with pci_irqd_intx_xlate added.
>>
>> BTW:
>> I re-tested just now w/o Ravi's patch and the INTx worked. Still I think
>> Ravi's patch is valid and should be applied...
> 
> How come INTx is working without the patch from Ravi which enabled INTx routing
> in the controller? Was it enabled by default in the hardware?

Yes, this is my best guess right now. I could double-check here, but
IMHO it makes sense to enable it "manually" as done with Ravi's patch
to not rely on this default setup at all.

Thanks,
Stefan

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

[Havalige, Thippeswamy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Stefan,

> -----Original Message-----
> From: Stefan Roese <stefan.roese@mailbox.org>
> Sent: Wednesday, October 22, 2025 3:29 PM
> To: mani@kernel.org
> Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> <ravib@amazon.com>; Havalige, Thippeswamy
> <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> bhelgaas@google.com; linux-pci@vger.kernel.org; kwilczynski@kernel.org;
> robh@kernel.org; Simek, Michal <michal.simek@amd.com>; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> stable@vger.kernel.org; Sean Anderson <sean.anderson@linux.dev>
> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>
> On 10/22/25 11:55, mani@kernel.org wrote:
> > On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> >> Hi Bjorn,
> >> Hi Ravi,
> >>
> >> On 10/21/25 23:28, Bjorn Helgaas wrote:
> >>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> >>>>> 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@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
> >>>>>>>> [...]
> >>
> >> First a comment on this IRQ logging:
> >>
> >> These lines do NOT refer to the INTx IRQ(s) but the controller
> >> internal "events" (errors etc). Please see this log for INTx on my
> >> Versal platform with pci_irqd_intx_xlate added:
> >>
> >>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> >>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> >>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> >>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> >>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> >>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> >>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> >>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> >>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> >>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> >>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> >>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> >>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> >>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> >>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> >>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> >>
> >> The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
> >> Event').
> >>
> >> More below...
> >>
> >>>>>>>>
> >>>>>>>> Changes since v1::
> >>>>>>>> - Fixed commit message per reviewer's comments
> >>>>>>>>
> >>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root
> >>>>>>>> Port driver")
> >>>>>>>> Cc: stable@vger.kernel.org
> >>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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@m
> >>>>>>> ailbox.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.
> >>>
> >>> OK, I'll assume the interrupts happened but the driver might not
> >>> have been able to handle them correctly, e.g., it was prepared for
> >>> INTA but got INTB or similar.
> >>>
> >>>>>    - 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.
> >>>
> >>> Stefan clarified in a private message that he had applied your patch
> >>> first, so this mystery is solved.
> >>
> >> Yes. I applied Ravi's patch first and still got no INTx delivered to
> >> the nvme driver. That's what me triggered to dig deeper here and
> >> resulted in this v2 patch with pci_irqd_intx_xlate added.
> >>
> >> BTW:
> >> I re-tested just now w/o Ravi's patch and the INTx worked. Still I
> >> think Ravi's patch is valid and should be applied...
> >
> > How come INTx is working without the patch from Ravi which enabled
> > INTx routing in the controller? Was it enabled by default in the hardware?
>
> Yes, this is my best guess right now. I could double-check here, but IMHO it
> makes sense to enable it "manually" as done with Ravi's patch to not rely on
> this default setup at all.
Hardware doesn't enable this bits by default, INTx didn't work since there is a miss match in the DT property which doesn't require pci_irqd_intx_xlate.

interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
<0 0 0 2 &pcie_intc_0 1>,
<0 0 0 3 &pcie_intc_0 2>,
<0 0 0 4 &pcie_intc_0 3>;

>
> Thanks,
> Stefan

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

[mani]

On Wed, Oct 22, 2025 at 10:08:44AM +0000, Havalige, Thippeswamy wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> Hi Stefan,
> 
> > -----Original Message-----
> > From: Stefan Roese <stefan.roese@mailbox.org>
> > Sent: Wednesday, October 22, 2025 3:29 PM
> > To: mani@kernel.org
> > Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> > <ravib@amazon.com>; Havalige, Thippeswamy
> > <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> > bhelgaas@google.com; linux-pci@vger.kernel.org; kwilczynski@kernel.org;
> > robh@kernel.org; Simek, Michal <michal.simek@amd.com>; linux-arm-
> > kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> > stable@vger.kernel.org; Sean Anderson <sean.anderson@linux.dev>
> > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> >
> > On 10/22/25 11:55, mani@kernel.org wrote:
> > > On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> > >> Hi Bjorn,
> > >> Hi Ravi,
> > >>
> > >> On 10/21/25 23:28, Bjorn Helgaas wrote:
> > >>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > >>>>> 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@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
> > >>>>>>>> [...]
> > >>
> > >> First a comment on this IRQ logging:
> > >>
> > >> These lines do NOT refer to the INTx IRQ(s) but the controller
> > >> internal "events" (errors etc). Please see this log for INTx on my
> > >> Versal platform with pci_irqd_intx_xlate added:
> > >>
> > >>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> > >>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> > >>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> > >>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> > >>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> > >>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> > >>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> > >>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> > >>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> > >>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> > >>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> > >>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> > >>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> > >>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> > >>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> > >>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > >>
> > >> The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
> > >> Event').
> > >>
> > >> More below...
> > >>
> > >>>>>>>>
> > >>>>>>>> Changes since v1::
> > >>>>>>>> - Fixed commit message per reviewer's comments
> > >>>>>>>>
> > >>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root
> > >>>>>>>> Port driver")
> > >>>>>>>> Cc: stable@vger.kernel.org
> > >>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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@m
> > >>>>>>> ailbox.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.
> > >>>
> > >>> OK, I'll assume the interrupts happened but the driver might not
> > >>> have been able to handle them correctly, e.g., it was prepared for
> > >>> INTA but got INTB or similar.
> > >>>
> > >>>>>    - 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.
> > >>>
> > >>> Stefan clarified in a private message that he had applied your patch
> > >>> first, so this mystery is solved.
> > >>
> > >> Yes. I applied Ravi's patch first and still got no INTx delivered to
> > >> the nvme driver. That's what me triggered to dig deeper here and
> > >> resulted in this v2 patch with pci_irqd_intx_xlate added.
> > >>
> > >> BTW:
> > >> I re-tested just now w/o Ravi's patch and the INTx worked. Still I
> > >> think Ravi's patch is valid and should be applied...
> > >
> > > How come INTx is working without the patch from Ravi which enabled
> > > INTx routing in the controller? Was it enabled by default in the hardware?
> >
> > Yes, this is my best guess right now. I could double-check here, but IMHO it
> > makes sense to enable it "manually" as done with Ravi's patch to not rely on
> > this default setup at all.
> Hardware doesn't enable this bits by default, INTx didn't work since there is a miss match in the DT property which doesn't require pci_irqd_intx_xlate.
> 
> interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> <0 0 0 2 &pcie_intc_0 1>,
> <0 0 0 3 &pcie_intc_0 2>,
> <0 0 0 4 &pcie_intc_0 3>;
> 

Ok. This makes me believe that we do not need Stefan's patch [1] and need just
this patch from Ravi.

- Mani

[1] https://lore.kernel.org/linux-pci/20251021154322.973640-1-stefan.roese@mailbox.org/

-- 
மணிவண்ணன் சதாசிவம்

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

[Havalige, Thippeswamy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Mani,

> -----Original Message-----
> From: mani@kernel.org <mani@kernel.org>
> Sent: Wednesday, October 22, 2025 4:02 PM
> To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> Cc: Stefan Roese <stefan.roese@mailbox.org>; Bjorn Helgaas
> <helgaas@kernel.org>; Bandi, Ravi Kumar <ravib@amazon.com>;
> lpieralisi@kernel.org; bhelgaas@google.com; linux-pci@vger.kernel.org;
> kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> <sean.anderson@linux.dev>
> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>
> On Wed, Oct 22, 2025 at 10:08:44AM +0000, Havalige, Thippeswamy wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > Hi Stefan,
> >
> > > -----Original Message-----
> > > From: Stefan Roese <stefan.roese@mailbox.org>
> > > Sent: Wednesday, October 22, 2025 3:29 PM
> > > To: mani@kernel.org
> > > Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> > > <ravib@amazon.com>; Havalige, Thippeswamy
> > > <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> > > bhelgaas@google.com; linux-pci@vger.kernel.org;
> > > kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> > > <michal.simek@amd.com>; linux-arm- kernel@lists.infradead.org;
> > > linux-kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> > > <sean.anderson@linux.dev>
> > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> > >
> > > On 10/22/25 11:55, mani@kernel.org wrote:
> > > > On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> > > >> Hi Bjorn,
> > > >> Hi Ravi,
> > > >>
> > > >> On 10/21/25 23:28, Bjorn Helgaas wrote:
> > > >>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > > >>>>> 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@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
> > > >>>>>>>> [...]
> > > >>
> > > >> First a comment on this IRQ logging:
> > > >>
> > > >> These lines do NOT refer to the INTx IRQ(s) but the controller
> > > >> internal "events" (errors etc). Please see this log for INTx on
> > > >> my Versal platform with pci_irqd_intx_xlate added:
> > > >>
> > > >>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> > > >>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> > > >>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> > > >>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> > > >>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> > > >>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> > > >>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> > > >>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> > > >>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> > > >>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> > > >>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> > > >>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> > > >>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> > > >>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> > > >>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> > > >>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > > >>
> > > >> The last line shows the INTx IRQs here ('pl_dma:INTx' vs
> > > >> 'pl_dma:RC- Event').
> > > >>
> > > >> More below...
> > > >>
> > > >>>>>>>>
> > > >>>>>>>> Changes since v1::
> > > >>>>>>>> - Fixed commit message per reviewer's comments
> > > >>>>>>>>
> > > >>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA
> > > >>>>>>>> Root Port driver")
> > > >>>>>>>> Cc: stable@vger.kernel.org
> > > >>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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@m
> > > >>>>>>> ailbox.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.
> > > >>>
> > > >>> OK, I'll assume the interrupts happened but the driver might not
> > > >>> have been able to handle them correctly, e.g., it was prepared
> > > >>> for INTA but got INTB or similar.
> > > >>>
> > > >>>>>    - 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.
> > > >>>
> > > >>> Stefan clarified in a private message that he had applied your
> > > >>> patch first, so this mystery is solved.
> > > >>
> > > >> Yes. I applied Ravi's patch first and still got no INTx delivered
> > > >> to the nvme driver. That's what me triggered to dig deeper here
> > > >> and resulted in this v2 patch with pci_irqd_intx_xlate added.
> > > >>
> > > >> BTW:
> > > >> I re-tested just now w/o Ravi's patch and the INTx worked. Still
> > > >> I think Ravi's patch is valid and should be applied...
> > > >
> > > > How come INTx is working without the patch from Ravi which enabled
> > > > INTx routing in the controller? Was it enabled by default in the hardware?
> > >
> > > Yes, this is my best guess right now. I could double-check here, but
> > > IMHO it makes sense to enable it "manually" as done with Ravi's
> > > patch to not rely on this default setup at all.
> > Hardware doesn't enable this bits by default, INTx didn't work since there is a
> miss match in the DT property which doesn't require pci_irqd_intx_xlate.
> >
> > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> > <0 0 0 2 &pcie_intc_0 1>,
> > <0 0 0 3 &pcie_intc_0 2>,
> > <0 0 0 4 &pcie_intc_0 3>;
> >
>
> Ok. This makes me believe that we do not need Stefan's patch [1] and need
> just this patch from Ravi.
>
> - Mani
>
> [1] https://lore.kernel.org/linux-pci/20251021154322.973640-1-
> stefan.roese@mailbox.org/

We even don’t need ravi patch, as we have tested this at our end it works fine by just updating interrupt-map
Property. We need to now understand the difference in design.
>
> --
> மணிவண்ணன் சதாசிவம்

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

[mani]

On Wed, Oct 22, 2025 at 10:36:28AM +0000, Havalige, Thippeswamy wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> Hi Mani,
> 
> > -----Original Message-----
> > From: mani@kernel.org <mani@kernel.org>
> > Sent: Wednesday, October 22, 2025 4:02 PM
> > To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> > Cc: Stefan Roese <stefan.roese@mailbox.org>; Bjorn Helgaas
> > <helgaas@kernel.org>; Bandi, Ravi Kumar <ravib@amazon.com>;
> > lpieralisi@kernel.org; bhelgaas@google.com; linux-pci@vger.kernel.org;
> > kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> > <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> > kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> > <sean.anderson@linux.dev>
> > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> >
> > On Wed, Oct 22, 2025 at 10:08:44AM +0000, Havalige, Thippeswamy wrote:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > Hi Stefan,
> > >
> > > > -----Original Message-----
> > > > From: Stefan Roese <stefan.roese@mailbox.org>
> > > > Sent: Wednesday, October 22, 2025 3:29 PM
> > > > To: mani@kernel.org
> > > > Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> > > > <ravib@amazon.com>; Havalige, Thippeswamy
> > > > <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> > > > bhelgaas@google.com; linux-pci@vger.kernel.org;
> > > > kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> > > > <michal.simek@amd.com>; linux-arm- kernel@lists.infradead.org;
> > > > linux-kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> > > > <sean.anderson@linux.dev>
> > > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> > > >
> > > > On 10/22/25 11:55, mani@kernel.org wrote:
> > > > > On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> > > > >> Hi Bjorn,
> > > > >> Hi Ravi,
> > > > >>
> > > > >> On 10/21/25 23:28, Bjorn Helgaas wrote:
> > > > >>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > > > >>>>> 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@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
> > > > >>>>>>>> [...]
> > > > >>
> > > > >> First a comment on this IRQ logging:
> > > > >>
> > > > >> These lines do NOT refer to the INTx IRQ(s) but the controller
> > > > >> internal "events" (errors etc). Please see this log for INTx on
> > > > >> my Versal platform with pci_irqd_intx_xlate added:
> > > > >>
> > > > >>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> > > > >>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> > > > >>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> > > > >>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> > > > >>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> > > > >>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> > > > >>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> > > > >>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> > > > >>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> > > > >>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> > > > >>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> > > > >>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> > > > >>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> > > > >>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> > > > >>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> > > > >>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > > > >>
> > > > >> The last line shows the INTx IRQs here ('pl_dma:INTx' vs
> > > > >> 'pl_dma:RC- Event').
> > > > >>
> > > > >> More below...
> > > > >>
> > > > >>>>>>>>
> > > > >>>>>>>> Changes since v1::
> > > > >>>>>>>> - Fixed commit message per reviewer's comments
> > > > >>>>>>>>
> > > > >>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA
> > > > >>>>>>>> Root Port driver")
> > > > >>>>>>>> Cc: stable@vger.kernel.org
> > > > >>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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@m
> > > > >>>>>>> ailbox.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.
> > > > >>>
> > > > >>> OK, I'll assume the interrupts happened but the driver might not
> > > > >>> have been able to handle them correctly, e.g., it was prepared
> > > > >>> for INTA but got INTB or similar.
> > > > >>>
> > > > >>>>>    - 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.
> > > > >>>
> > > > >>> Stefan clarified in a private message that he had applied your
> > > > >>> patch first, so this mystery is solved.
> > > > >>
> > > > >> Yes. I applied Ravi's patch first and still got no INTx delivered
> > > > >> to the nvme driver. That's what me triggered to dig deeper here
> > > > >> and resulted in this v2 patch with pci_irqd_intx_xlate added.
> > > > >>
> > > > >> BTW:
> > > > >> I re-tested just now w/o Ravi's patch and the INTx worked. Still
> > > > >> I think Ravi's patch is valid and should be applied...
> > > > >
> > > > > How come INTx is working without the patch from Ravi which enabled
> > > > > INTx routing in the controller? Was it enabled by default in the hardware?
> > > >
> > > > Yes, this is my best guess right now. I could double-check here, but
> > > > IMHO it makes sense to enable it "manually" as done with Ravi's
> > > > patch to not rely on this default setup at all.
> > > Hardware doesn't enable this bits by default, INTx didn't work since there is a
> > miss match in the DT property which doesn't require pci_irqd_intx_xlate.
> > >
> > > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> > > <0 0 0 2 &pcie_intc_0 1>,
> > > <0 0 0 3 &pcie_intc_0 2>,
> > > <0 0 0 4 &pcie_intc_0 3>;
> > >
> >
> > Ok. This makes me believe that we do not need Stefan's patch [1] and need
> > just this patch from Ravi.
> >
> > - Mani
> >
> > [1] https://lore.kernel.org/linux-pci/20251021154322.973640-1-
> > stefan.roese@mailbox.org/
> 
> We even don’t need ravi patch, as we have tested this at our end it works fine by just updating interrupt-map
> Property. We need to now understand the difference in design.

Ok, please let us know with your findings. In the meantime, I'll keep Ravi's
patch in tree, as it seems to be required on his setup.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Musham, Sai Krishna]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Mani,

> -----Original Message-----
> From: mani@kernel.org <mani@kernel.org>
> Sent: Wednesday, October 22, 2025 4:28 PM
> To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> Cc: Stefan Roese <stefan.roese@mailbox.org>; Bjorn Helgaas
> <helgaas@kernel.org>; Bandi, Ravi Kumar <ravib@amazon.com>;
> lpieralisi@kernel.org; bhelgaas@google.com; linux-pci@vger.kernel.org;
> kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> <sean.anderson@linux.dev>; Yeleswarapu, Nagaradhesh
> <nagaradhesh.yeleswarapu@amd.com>; Musham, Sai Krishna
> <sai.krishna.musham@amd.com>
> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, Oct 22, 2025 at 10:36:28AM +0000, Havalige, Thippeswamy wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > Hi Mani,
> >
> > > -----Original Message-----
> > > From: mani@kernel.org <mani@kernel.org>
> > > Sent: Wednesday, October 22, 2025 4:02 PM
> > > To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> > > Cc: Stefan Roese <stefan.roese@mailbox.org>; Bjorn Helgaas
> > > <helgaas@kernel.org>; Bandi, Ravi Kumar <ravib@amazon.com>;
> > > lpieralisi@kernel.org; bhelgaas@google.com;
> > > linux-pci@vger.kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> > > Simek, Michal <michal.simek@amd.com>;
> > > linux-arm-kernel@lists.infradead.org; linux- kernel@vger.kernel.org;
> > > stable@vger.kernel.org; Sean Anderson <sean.anderson@linux.dev>
> > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> > >
> > > On Wed, Oct 22, 2025 at 10:08:44AM +0000, Havalige, Thippeswamy wrote:
> > > > [AMD Official Use Only - AMD Internal Distribution Only]
> > > >
> > > > Hi Stefan,
> > > >
> > > > > -----Original Message-----
> > > > > From: Stefan Roese <stefan.roese@mailbox.org>
> > > > > Sent: Wednesday, October 22, 2025 3:29 PM
> > > > > To: mani@kernel.org
> > > > > Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> > > > > <ravib@amazon.com>; Havalige, Thippeswamy
> > > > > <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> > > > > bhelgaas@google.com; linux-pci@vger.kernel.org;
> > > > > kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> > > > > <michal.simek@amd.com>; linux-arm- kernel@lists.infradead.org;
> > > > > linux-kernel@vger.kernel.org; stable@vger.kernel.org; Sean
> > > > > Anderson <sean.anderson@linux.dev>
> > > > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> > > > >
> > > > > On 10/22/25 11:55, mani@kernel.org wrote:
> > > > > > On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> > > > > >> Hi Bjorn,
> > > > > >> Hi Ravi,
> > > > > >>
> > > > > >> On 10/21/25 23:28, Bjorn Helgaas wrote:
> > > > > >>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > > > > >>>>> 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@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
> > > > > >>>>>>>> [...]
> > > > > >>
> > > > > >> First a comment on this IRQ logging:
> > > > > >>
> > > > > >> These lines do NOT refer to the INTx IRQ(s) but the
> > > > > >> controller internal "events" (errors etc). Please see this
> > > > > >> log for INTx on my Versal platform with pci_irqd_intx_xlate added:
> > > > > >>
> > > > > >>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> > > > > >>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> > > > > >>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> > > > > >>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> > > > > >>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> > > > > >>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> > > > > >>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> > > > > >>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> > > > > >>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> > > > > >>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> > > > > >>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> > > > > >>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> > > > > >>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> > > > > >>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> > > > > >>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> > > > > >>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > > > > >>
> > > > > >> The last line shows the INTx IRQs here ('pl_dma:INTx' vs
> > > > > >> 'pl_dma:RC- Event').
> > > > > >>
> > > > > >> More below...
> > > > > >>
> > > > > >>>>>>>>
> > > > > >>>>>>>> Changes since v1::
> > > > > >>>>>>>> - Fixed commit message per reviewer's comments
> > > > > >>>>>>>>
> > > > > >>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA
> > > > > >>>>>>>> Root Port driver")
> > > > > >>>>>>>> Cc: stable@vger.kernel.org
> > > > > >>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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@m
> > > > > >>>>>>> ailbox.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.
> > > > > >>>
> > > > > >>> OK, I'll assume the interrupts happened but the driver might
> > > > > >>> not have been able to handle them correctly, e.g., it was
> > > > > >>> prepared for INTA but got INTB or similar.
> > > > > >>>
> > > > > >>>>>    - 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.
> > > > > >>>
> > > > > >>> Stefan clarified in a private message that he had applied
> > > > > >>> your patch first, so this mystery is solved.
> > > > > >>
> > > > > >> Yes. I applied Ravi's patch first and still got no INTx
> > > > > >> delivered to the nvme driver. That's what me triggered to dig
> > > > > >> deeper here and resulted in this v2 patch with pci_irqd_intx_xlate added.
> > > > > >>
> > > > > >> BTW:
> > > > > >> I re-tested just now w/o Ravi's patch and the INTx worked.
> > > > > >> Still I think Ravi's patch is valid and should be applied...
> > > > > >
> > > > > > How come INTx is working without the patch from Ravi which
> > > > > > enabled INTx routing in the controller? Was it enabled by default in the
> hardware?
> > > > >
> > > > > Yes, this is my best guess right now. I could double-check here,
> > > > > but IMHO it makes sense to enable it "manually" as done with
> > > > > Ravi's patch to not rely on this default setup at all.
> > > > Hardware doesn't enable this bits by default, INTx didn't work
> > > > since there is a
> > > miss match in the DT property which doesn't require pci_irqd_intx_xlate.
> > > >
> > > > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> > > > <0 0 0 2 &pcie_intc_0 1>,
> > > > <0 0 0 3 &pcie_intc_0 2>,
> > > > <0 0 0 4 &pcie_intc_0 3>;
> > > >
> > >
> > > Ok. This makes me believe that we do not need Stefan's patch [1] and
> > > need just this patch from Ravi.
> > >
> > > - Mani
> > >
> > > [1] https://lore.kernel.org/linux-pci/20251021154322.973640-1-
> > > stefan.roese@mailbox.org/
> >
> > We even don’t need ravi patch, as we have tested this at our end it
> > works fine by just updating interrupt-map Property. We need to now understand the
> difference in design.
>
> Ok, please let us know with your findings. In the meantime, I'll keep Ravi's patch in
> tree, as it seems to be required on his setup.
>

We tested on Linux version 6.12.40 without applying either Stefan's or Ravi's patches.
Instead, we applied only the following interrupt-map property change (entries 0,1,2,3) and verified that
legacy interrupts are working correctly.

interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
<0 0 0 2 &pcie_intc_0 1>,
<0 0 0 3 &pcie_intc_0 2>,
<0 0 0 4 &pcie_intc_0 3>;

38:       1143          0  pl_dma:RC-Event  16 Level     80000000.axi-pcie
39:       1143          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1

Thanks,
Sai Krishna

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

[mani]

On Wed, Oct 22, 2025 at 12:48:27PM +0000, Musham, Sai Krishna wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> Hi Mani,
> 
> > -----Original Message-----
> > From: mani@kernel.org <mani@kernel.org>
> > Sent: Wednesday, October 22, 2025 4:28 PM
> > To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> > Cc: Stefan Roese <stefan.roese@mailbox.org>; Bjorn Helgaas
> > <helgaas@kernel.org>; Bandi, Ravi Kumar <ravib@amazon.com>;
> > lpieralisi@kernel.org; bhelgaas@google.com; linux-pci@vger.kernel.org;
> > kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> > <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> > kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> > <sean.anderson@linux.dev>; Yeleswarapu, Nagaradhesh
> > <nagaradhesh.yeleswarapu@amd.com>; Musham, Sai Krishna
> > <sai.krishna.musham@amd.com>
> > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Oct 22, 2025 at 10:36:28AM +0000, Havalige, Thippeswamy wrote:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > Hi Mani,
> > >
> > > > -----Original Message-----
> > > > From: mani@kernel.org <mani@kernel.org>
> > > > Sent: Wednesday, October 22, 2025 4:02 PM
> > > > To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> > > > Cc: Stefan Roese <stefan.roese@mailbox.org>; Bjorn Helgaas
> > > > <helgaas@kernel.org>; Bandi, Ravi Kumar <ravib@amazon.com>;
> > > > lpieralisi@kernel.org; bhelgaas@google.com;
> > > > linux-pci@vger.kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> > > > Simek, Michal <michal.simek@amd.com>;
> > > > linux-arm-kernel@lists.infradead.org; linux- kernel@vger.kernel.org;
> > > > stable@vger.kernel.org; Sean Anderson <sean.anderson@linux.dev>
> > > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> > > >
> > > > On Wed, Oct 22, 2025 at 10:08:44AM +0000, Havalige, Thippeswamy wrote:
> > > > > [AMD Official Use Only - AMD Internal Distribution Only]
> > > > >
> > > > > Hi Stefan,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stefan Roese <stefan.roese@mailbox.org>
> > > > > > Sent: Wednesday, October 22, 2025 3:29 PM
> > > > > > To: mani@kernel.org
> > > > > > Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> > > > > > <ravib@amazon.com>; Havalige, Thippeswamy
> > > > > > <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> > > > > > bhelgaas@google.com; linux-pci@vger.kernel.org;
> > > > > > kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> > > > > > <michal.simek@amd.com>; linux-arm- kernel@lists.infradead.org;
> > > > > > linux-kernel@vger.kernel.org; stable@vger.kernel.org; Sean
> > > > > > Anderson <sean.anderson@linux.dev>
> > > > > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> > > > > >
> > > > > > On 10/22/25 11:55, mani@kernel.org wrote:
> > > > > > > On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> > > > > > >> Hi Bjorn,
> > > > > > >> Hi Ravi,
> > > > > > >>
> > > > > > >> On 10/21/25 23:28, Bjorn Helgaas wrote:
> > > > > > >>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > > > > > >>>>> 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@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
> > > > > > >>>>>>>> [...]
> > > > > > >>
> > > > > > >> First a comment on this IRQ logging:
> > > > > > >>
> > > > > > >> These lines do NOT refer to the INTx IRQ(s) but the
> > > > > > >> controller internal "events" (errors etc). Please see this
> > > > > > >> log for INTx on my Versal platform with pci_irqd_intx_xlate added:
> > > > > > >>
> > > > > > >>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> > > > > > >>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> > > > > > >>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> > > > > > >>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> > > > > > >>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> > > > > > >>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> > > > > > >>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> > > > > > >>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> > > > > > >>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> > > > > > >>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> > > > > > >>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> > > > > > >>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> > > > > > >>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> > > > > > >>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> > > > > > >>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> > > > > > >>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > > > > > >>
> > > > > > >> The last line shows the INTx IRQs here ('pl_dma:INTx' vs
> > > > > > >> 'pl_dma:RC- Event').
> > > > > > >>
> > > > > > >> More below...
> > > > > > >>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Changes since v1::
> > > > > > >>>>>>>> - Fixed commit message per reviewer's comments
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA
> > > > > > >>>>>>>> Root Port driver")
> > > > > > >>>>>>>> Cc: stable@vger.kernel.org
> > > > > > >>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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@m
> > > > > > >>>>>>> ailbox.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.
> > > > > > >>>
> > > > > > >>> OK, I'll assume the interrupts happened but the driver might
> > > > > > >>> not have been able to handle them correctly, e.g., it was
> > > > > > >>> prepared for INTA but got INTB or similar.
> > > > > > >>>
> > > > > > >>>>>    - 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.
> > > > > > >>>
> > > > > > >>> Stefan clarified in a private message that he had applied
> > > > > > >>> your patch first, so this mystery is solved.
> > > > > > >>
> > > > > > >> Yes. I applied Ravi's patch first and still got no INTx
> > > > > > >> delivered to the nvme driver. That's what me triggered to dig
> > > > > > >> deeper here and resulted in this v2 patch with pci_irqd_intx_xlate added.
> > > > > > >>
> > > > > > >> BTW:
> > > > > > >> I re-tested just now w/o Ravi's patch and the INTx worked.
> > > > > > >> Still I think Ravi's patch is valid and should be applied...
> > > > > > >
> > > > > > > How come INTx is working without the patch from Ravi which
> > > > > > > enabled INTx routing in the controller? Was it enabled by default in the
> > hardware?
> > > > > >
> > > > > > Yes, this is my best guess right now. I could double-check here,
> > > > > > but IMHO it makes sense to enable it "manually" as done with
> > > > > > Ravi's patch to not rely on this default setup at all.
> > > > > Hardware doesn't enable this bits by default, INTx didn't work
> > > > > since there is a
> > > > miss match in the DT property which doesn't require pci_irqd_intx_xlate.
> > > > >
> > > > > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> > > > > <0 0 0 2 &pcie_intc_0 1>,
> > > > > <0 0 0 3 &pcie_intc_0 2>,
> > > > > <0 0 0 4 &pcie_intc_0 3>;
> > > > >
> > > >
> > > > Ok. This makes me believe that we do not need Stefan's patch [1] and
> > > > need just this patch from Ravi.
> > > >
> > > > - Mani
> > > >
> > > > [1] https://lore.kernel.org/linux-pci/20251021154322.973640-1-
> > > > stefan.roese@mailbox.org/
> > >
> > > We even don’t need ravi patch, as we have tested this at our end it
> > > works fine by just updating interrupt-map Property. We need to now understand the
> > difference in design.
> >
> > Ok, please let us know with your findings. In the meantime, I'll keep Ravi's patch in
> > tree, as it seems to be required on his setup.
> >
> 
> We tested on Linux version 6.12.40 without applying either Stefan's or Ravi's patches.

Please test with v6.18-rc1 kernel.

Any clue on what is going wrong with Ravi's setup?
https://lore.kernel.org/linux-pci/467D7D30-DC05-4612-87BA-7E980A9C0A4A@amazon.com/

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Musham, Sai Krishna]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Mani,

> -----Original Message-----
> From: mani@kernel.org <mani@kernel.org>
> Sent: Wednesday, October 22, 2025 6:40 PM
> To: Musham, Sai Krishna <sai.krishna.musham@amd.com>
> Cc: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>; Stefan Roese
> <stefan.roese@mailbox.org>; Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi
> Kumar <ravib@amazon.com>; lpieralisi@kernel.org; bhelgaas@google.com; linux-
> pci@vger.kernel.org; kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> <sean.anderson@linux.dev>; Yeleswarapu, Nagaradhesh
> <nagaradhesh.yeleswarapu@amd.com>
> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, Oct 22, 2025 at 12:48:27PM +0000, Musham, Sai Krishna wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > Hi Mani,
> >
> > > -----Original Message-----
> > > From: mani@kernel.org <mani@kernel.org>
> > > Sent: Wednesday, October 22, 2025 4:28 PM
> > > To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> > > Cc: Stefan Roese <stefan.roese@mailbox.org>; Bjorn Helgaas
> > > <helgaas@kernel.org>; Bandi, Ravi Kumar <ravib@amazon.com>;
> > > lpieralisi@kernel.org; bhelgaas@google.com;
> > > linux-pci@vger.kernel.org; kwilczynski@kernel.org; robh@kernel.org;
> > > Simek, Michal <michal.simek@amd.com>;
> > > linux-arm-kernel@lists.infradead.org; linux- kernel@vger.kernel.org;
> > > stable@vger.kernel.org; Sean Anderson <sean.anderson@linux.dev>;
> > > Yeleswarapu, Nagaradhesh <nagaradhesh.yeleswarapu@amd.com>; Musham,
> > > Sai Krishna <sai.krishna.musham@amd.com>
> > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > On Wed, Oct 22, 2025 at 10:36:28AM +0000, Havalige, Thippeswamy wrote:
> > > > [AMD Official Use Only - AMD Internal Distribution Only]
> > > >
> > > > Hi Mani,
> > > >
> > > > > -----Original Message-----
> > > > > From: mani@kernel.org <mani@kernel.org>
> > > > > Sent: Wednesday, October 22, 2025 4:02 PM
> > > > > To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> > > > > Cc: Stefan Roese <stefan.roese@mailbox.org>; Bjorn Helgaas
> > > > > <helgaas@kernel.org>; Bandi, Ravi Kumar <ravib@amazon.com>;
> > > > > lpieralisi@kernel.org; bhelgaas@google.com;
> > > > > linux-pci@vger.kernel.org; kwilczynski@kernel.org;
> > > > > robh@kernel.org; Simek, Michal <michal.simek@amd.com>;
> > > > > linux-arm-kernel@lists.infradead.org; linux-
> > > > > kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> > > > > <sean.anderson@linux.dev>
> > > > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> > > > >
> > > > > On Wed, Oct 22, 2025 at 10:08:44AM +0000, Havalige, Thippeswamy wrote:
> > > > > > [AMD Official Use Only - AMD Internal Distribution Only]
> > > > > >
> > > > > > Hi Stefan,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stefan Roese <stefan.roese@mailbox.org>
> > > > > > > Sent: Wednesday, October 22, 2025 3:29 PM
> > > > > > > To: mani@kernel.org
> > > > > > > Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> > > > > > > <ravib@amazon.com>; Havalige, Thippeswamy
> > > > > > > <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> > > > > > > bhelgaas@google.com; linux-pci@vger.kernel.org;
> > > > > > > kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> > > > > > > <michal.simek@amd.com>; linux-arm-
> > > > > > > kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > > > > > stable@vger.kernel.org; Sean Anderson
> > > > > > > <sean.anderson@linux.dev>
> > > > > > > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx
> > > > > > > interrupts
> > > > > > >
> > > > > > > On 10/22/25 11:55, mani@kernel.org wrote:
> > > > > > > > On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> > > > > > > >> Hi Bjorn,
> > > > > > > >> Hi Ravi,
> > > > > > > >>
> > > > > > > >> On 10/21/25 23:28, Bjorn Helgaas wrote:
> > > > > > > >>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar
> wrote:
> > > > > > > >>>>> 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@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
> > > > > > > >>>>>>>> [...]
> > > > > > > >>
> > > > > > > >> First a comment on this IRQ logging:
> > > > > > > >>
> > > > > > > >> These lines do NOT refer to the INTx IRQ(s) but the
> > > > > > > >> controller internal "events" (errors etc). Please see
> > > > > > > >> this log for INTx on my Versal platform with pci_irqd_intx_xlate
> added:
> > > > > > > >>
> > > > > > > >>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> > > > > > > >>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> > > > > > > >>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> > > > > > > >>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> > > > > > > >>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> > > > > > > >>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> > > > > > > >>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> > > > > > > >>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> > > > > > > >>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> > > > > > > >>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> > > > > > > >>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> > > > > > > >>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> > > > > > > >>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> > > > > > > >>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> > > > > > > >>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-
> pcie
> > > > > > > >>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > > > > > > >>
> > > > > > > >> The last line shows the INTx IRQs here ('pl_dma:INTx' vs
> > > > > > > >> 'pl_dma:RC- Event').
> > > > > > > >>
> > > > > > > >> More below...
> > > > > > > >>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Changes since v1::
> > > > > > > >>>>>>>> - Fixed commit message per reviewer's comments
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx
> > > > > > > >>>>>>>> XDMA Root Port driver")
> > > > > > > >>>>>>>> Cc: stable@vger.kernel.org
> > > > > > > >>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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@m
> > > > > > > >>>>>>> ailbox.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.
> > > > > > > >>>
> > > > > > > >>> OK, I'll assume the interrupts happened but the driver
> > > > > > > >>> might not have been able to handle them correctly, e.g.,
> > > > > > > >>> it was prepared for INTA but got INTB or similar.
> > > > > > > >>>
> > > > > > > >>>>>    - 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.
> > > > > > > >>>
> > > > > > > >>> Stefan clarified in a private message that he had
> > > > > > > >>> applied your patch first, so this mystery is solved.
> > > > > > > >>
> > > > > > > >> Yes. I applied Ravi's patch first and still got no INTx
> > > > > > > >> delivered to the nvme driver. That's what me triggered to
> > > > > > > >> dig deeper here and resulted in this v2 patch with pci_irqd_intx_xlate
> added.
> > > > > > > >>
> > > > > > > >> BTW:
> > > > > > > >> I re-tested just now w/o Ravi's patch and the INTx worked.
> > > > > > > >> Still I think Ravi's patch is valid and should be applied...
> > > > > > > >
> > > > > > > > How come INTx is working without the patch from Ravi which
> > > > > > > > enabled INTx routing in the controller? Was it enabled by
> > > > > > > > default in the
> > > hardware?
> > > > > > >
> > > > > > > Yes, this is my best guess right now. I could double-check
> > > > > > > here, but IMHO it makes sense to enable it "manually" as
> > > > > > > done with Ravi's patch to not rely on this default setup at all.
> > > > > > Hardware doesn't enable this bits by default, INTx didn't work
> > > > > > since there is a
> > > > > miss match in the DT property which doesn't require pci_irqd_intx_xlate.
> > > > > >
> > > > > > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> > > > > > <0 0 0 2 &pcie_intc_0 1>,
> > > > > > <0 0 0 3 &pcie_intc_0 2>,
> > > > > > <0 0 0 4 &pcie_intc_0 3>;
> > > > > >
> > > > >
> > > > > Ok. This makes me believe that we do not need Stefan's patch [1]
> > > > > and need just this patch from Ravi.
> > > > >
> > > > > - Mani
> > > > >
> > > > > [1] https://lore.kernel.org/linux-pci/20251021154322.973640-1-
> > > > > stefan.roese@mailbox.org/
> > > >
> > > > We even don’t need ravi patch, as we have tested this at our end
> > > > it works fine by just updating interrupt-map Property. We need to
> > > > now understand the
> > > difference in design.
> > >
> > > Ok, please let us know with your findings. In the meantime, I'll
> > > keep Ravi's patch in tree, as it seems to be required on his setup.
> > >
> >
> > We tested on Linux version 6.12.40 without applying either Stefan's or Ravi's
> patches.
>
> Please test with v6.18-rc1 kernel.
>

We have tested with the v6.18-rc1 kernel without applying either patch.
With the interrupt-map property change, legacy interrupts are functioning
correctly on this kernel.

> Any clue on what is going wrong with Ravi's setup?
> https://lore.kernel.org/linux-pci/467D7D30-DC05-4612-87BA-
> 7E980A9C0A4A@amazon.com/
>

We are getting the required details on this. Thanks.

> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்

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

[Stefan Roese]

On 10/22/25 14:48, Musham, Sai Krishna wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]

<snip>

>>> We even don’t need ravi patch, as we have tested this at our end it
>>> works fine by just updating interrupt-map Property. We need to now understand the
>> difference in design.
>>
>> Ok, please let us know with your findings. In the meantime, I'll keep Ravi's patch in
>> tree, as it seems to be required on his setup.
>>
> 
> We tested on Linux version 6.12.40 without applying either Stefan's or Ravi's patches.
> Instead, we applied only the following interrupt-map property change (entries 0,1,2,3) and verified that
> legacy interrupts are working correctly.
> 
> interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> <0 0 0 2 &pcie_intc_0 1>,
> <0 0 0 3 &pcie_intc_0 2>,
> <0 0 0 4 &pcie_intc_0 3>;
> 
> 38:       1143          0  pl_dma:RC-Event  16 Level     80000000.axi-pcie
> 39:       1143          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1

Okay. Same here. I don't need Ravi's patch for the INTx bit enabling.

I understand that you want us to change the interrupt map in the auto-
generated device-tree from Vivado. Which is IMHO a bit "suboptimal".

I would prefer to have a solution which works out-of-the-box, w/o the
need to manually change DT properties. Is it planned to change / fix
this interrupt map in pl.dtsi generated with a newer version of Vivado?

Thanks,
Stefan

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

[Musham, Sai Krishna]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Stefan Roese <stefan.roese@mailbox.org>
> Sent: Wednesday, October 22, 2025 7:08 PM
> To: Musham, Sai Krishna <sai.krishna.musham@amd.com>; mani@kernel.org;
> Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
> Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> <ravib@amazon.com>; lpieralisi@kernel.org; bhelgaas@google.com; linux-
> pci@vger.kernel.org; kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> <sean.anderson@linux.dev>; Yeleswarapu, Nagaradhesh
> <nagaradhesh.yeleswarapu@amd.com>
> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 10/22/25 14:48, Musham, Sai Krishna wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
>
> <snip>
>
> >>> We even don’t need ravi patch, as we have tested this at our end it
> >>> works fine by just updating interrupt-map Property. We need to now
> >>> understand the
> >> difference in design.
> >>
> >> Ok, please let us know with your findings. In the meantime, I'll keep
> >> Ravi's patch in tree, as it seems to be required on his setup.
> >>
> >
> > We tested on Linux version 6.12.40 without applying either Stefan's or Ravi's
> patches.
> > Instead, we applied only the following interrupt-map property change
> > (entries 0,1,2,3) and verified that legacy interrupts are working correctly.
> >
> > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> > <0 0 0 2 &pcie_intc_0 1>,
> > <0 0 0 3 &pcie_intc_0 2>,
> > <0 0 0 4 &pcie_intc_0 3>;
> >
> > 38:       1143          0  pl_dma:RC-Event  16 Level     80000000.axi-pcie
> > 39:       1143          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
>
> Okay. Same here. I don't need Ravi's patch for the INTx bit enabling.
>
> I understand that you want us to change the interrupt map in the auto- generated
> device-tree from Vivado. Which is IMHO a bit "suboptimal".
>
> I would prefer to have a solution which works out-of-the-box, w/o the need to
> manually change DT properties. Is it planned to change / fix this interrupt map in
> pl.dtsi generated with a newer version of Vivado?
>

Yes Stefan, this will be fixed in the newer versions and the auto-generated
device tree will include the correct interrupt-map property entries.

> Thanks,
> Stefan

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

[Stefan Roese]

On 10/23/25 08:35, Musham, Sai Krishna wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
>> -----Original Message-----
>> From: Stefan Roese <stefan.roese@mailbox.org>
>> Sent: Wednesday, October 22, 2025 7:08 PM
>> To: Musham, Sai Krishna <sai.krishna.musham@amd.com>; mani@kernel.org;
>> Havalige, Thippeswamy <thippeswamy.havalige@amd.com>
>> Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
>> <ravib@amazon.com>; lpieralisi@kernel.org; bhelgaas@google.com; linux-
>> pci@vger.kernel.org; kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
>> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
>> <sean.anderson@linux.dev>; Yeleswarapu, Nagaradhesh
>> <nagaradhesh.yeleswarapu@amd.com>
>> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>>
>> Caution: This message originated from an External Source. Use proper caution
>> when opening attachments, clicking links, or responding.
>>
>>
>> On 10/22/25 14:48, Musham, Sai Krishna wrote:
>>> [AMD Official Use Only - AMD Internal Distribution Only]
>>
>> <snip>
>>
>>>>> We even don’t need ravi patch, as we have tested this at our end it
>>>>> works fine by just updating interrupt-map Property. We need to now
>>>>> understand the
>>>> difference in design.
>>>>
>>>> Ok, please let us know with your findings. In the meantime, I'll keep
>>>> Ravi's patch in tree, as it seems to be required on his setup.
>>>>
>>>
>>> We tested on Linux version 6.12.40 without applying either Stefan's or Ravi's
>> patches.
>>> Instead, we applied only the following interrupt-map property change
>>> (entries 0,1,2,3) and verified that legacy interrupts are working correctly.
>>>
>>> interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
>>> <0 0 0 2 &pcie_intc_0 1>,
>>> <0 0 0 3 &pcie_intc_0 2>,
>>> <0 0 0 4 &pcie_intc_0 3>;
>>>
>>> 38:       1143          0  pl_dma:RC-Event  16 Level     80000000.axi-pcie
>>> 39:       1143          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
>>
>> Okay. Same here. I don't need Ravi's patch for the INTx bit enabling.
>>
>> I understand that you want us to change the interrupt map in the auto- generated
>> device-tree from Vivado. Which is IMHO a bit "suboptimal".
>>
>> I would prefer to have a solution which works out-of-the-box, w/o the need to
>> manually change DT properties. Is it planned to change / fix this interrupt map in
>> pl.dtsi generated with a newer version of Vivado?
>>
> 
> Yes Stefan, this will be fixed in the newer versions and the auto-generated
> device tree will include the correct interrupt-map property entries.

Understood. And thanks the update on this.

@Bjorn & Mani, this patch can be dropped then.

Thanks,
Stefan

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

[Bjorn Helgaas]

On Thu, Oct 23, 2025 at 09:03:07AM +0200, Stefan Roese wrote:
> On 10/23/25 08:35, Musham, Sai Krishna wrote:
> > > -----Original Message-----
> > > From: Stefan Roese <stefan.roese@mailbox.org>
> > > On 10/22/25 14:48, Musham, Sai Krishna wrote:
> ...

> > > > > > We even don’t need ravi patch, as we have tested this at
> > > > > > our end it works fine by just updating interrupt-map
> > > > > > Property. We need to now understand the difference in
> > > > > > design.
> > > > > 
> > > > > Ok, please let us know with your findings. In the meantime,
> > > > > I'll keep Ravi's patch in tree, as it seems to be required
> > > > > on his setup.
> > > > 
> > > > We tested on Linux version 6.12.40 without applying either
> > > > Stefan's or Ravi's patches.  Instead, we applied only the
> > > > following interrupt-map property change (entries 0,1,2,3) and
> > > > verified that legacy interrupts are working correctly.
> > > > 
> > > > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> > > > <0 0 0 2 &pcie_intc_0 1>,
> > > > <0 0 0 3 &pcie_intc_0 2>,
> > > > <0 0 0 4 &pcie_intc_0 3>;
> > > > 
> > > > 38:       1143          0  pl_dma:RC-Event  16 Level     80000000.axi-pcie
> > > > 39:       1143          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > > 
> > > Okay. Same here. I don't need Ravi's patch for the INTx bit
> > > enabling.
> > > 
> > > I understand that you want us to change the interrupt map in the
> > > auto- generated device-tree from Vivado. Which is IMHO a bit
> > > "suboptimal".
> > > 
> > > I would prefer to have a solution which works out-of-the-box,
> > > w/o the need to manually change DT properties. Is it planned to
> > > change / fix this interrupt map in pl.dtsi generated with a
> > > newer version of Vivado?
> > 
> > Yes Stefan, this will be fixed in the newer versions and the
> > auto-generated device tree will include the correct interrupt-map
> > property entries.
> 
> Understood. And thanks the update on this.
> 
> @Bjorn & Mani, this patch can be dropped then.

Just to confirm, we can drop both of these patches:

  https://patch.msgid.link/20250920225232.18757-1-ravib@amazon.com
  https://patch.msgid.link/20251021154322.973640-1-stefan.roese@mailbox.org

AND there are no DTs in the field that will need to be updated for
things to work?

It's OK if you need to update internal DTs that haven't been shipped
to users, but we do not want to force users to update DTs that have
previously been working.

Bjorn

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

[mani]

On Thu, Oct 23, 2025 at 11:11:00AM -0500, Bjorn Helgaas wrote:
> On Thu, Oct 23, 2025 at 09:03:07AM +0200, Stefan Roese wrote:
> > On 10/23/25 08:35, Musham, Sai Krishna wrote:
> > > > -----Original Message-----
> > > > From: Stefan Roese <stefan.roese@mailbox.org>
> > > > On 10/22/25 14:48, Musham, Sai Krishna wrote:
> > ...
> 
> > > > > > > We even don’t need ravi patch, as we have tested this at
> > > > > > > our end it works fine by just updating interrupt-map
> > > > > > > Property. We need to now understand the difference in
> > > > > > > design.
> > > > > > 
> > > > > > Ok, please let us know with your findings. In the meantime,
> > > > > > I'll keep Ravi's patch in tree, as it seems to be required
> > > > > > on his setup.
> > > > > 
> > > > > We tested on Linux version 6.12.40 without applying either
> > > > > Stefan's or Ravi's patches.  Instead, we applied only the
> > > > > following interrupt-map property change (entries 0,1,2,3) and
> > > > > verified that legacy interrupts are working correctly.
> > > > > 
> > > > > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> > > > > <0 0 0 2 &pcie_intc_0 1>,
> > > > > <0 0 0 3 &pcie_intc_0 2>,
> > > > > <0 0 0 4 &pcie_intc_0 3>;
> > > > > 
> > > > > 38:       1143          0  pl_dma:RC-Event  16 Level     80000000.axi-pcie
> > > > > 39:       1143          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > > > 
> > > > Okay. Same here. I don't need Ravi's patch for the INTx bit
> > > > enabling.
> > > > 
> > > > I understand that you want us to change the interrupt map in the
> > > > auto- generated device-tree from Vivado. Which is IMHO a bit
> > > > "suboptimal".
> > > > 
> > > > I would prefer to have a solution which works out-of-the-box,
> > > > w/o the need to manually change DT properties. Is it planned to
> > > > change / fix this interrupt map in pl.dtsi generated with a
> > > > newer version of Vivado?
> > > 
> > > Yes Stefan, this will be fixed in the newer versions and the
> > > auto-generated device tree will include the correct interrupt-map
> > > property entries.
> > 
> > Understood. And thanks the update on this.
> > 
> > @Bjorn & Mani, this patch can be dropped then.
> 
> Just to confirm, we can drop both of these patches:
> 
>   https://patch.msgid.link/20250920225232.18757-1-ravib@amazon.com
>   https://patch.msgid.link/20251021154322.973640-1-stefan.roese@mailbox.org
> 
> AND there are no DTs in the field that will need to be updated for
> things to work?
> 

There are no upstream DTs making use of this driver. Also, the upstream binding
example seems to be correct:

            interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
                            <0 0 0 2 &pcie_intc_0 1>,
                            <0 0 0 3 &pcie_intc_0 2>,
                            <0 0 0 4 &pcie_intc_0 3>;

Moreover, if any DTs were using different 'interrupt-map' property, then INTx
wouldn't be working for them. So most likely they were all using MSIs as we
haven't received any reports up until now.

Hence, IMO we should be good to ignore the patch from Stefan. Though, I still
have a concern on whether the hardware is enabling INTx by default or not [1].
Until that is concluded, we should keep Ravi's patch.

- Mani

[1] https://lore.kernel.org/linux-pci/DM4PR12MB6158C6E6D6CC8BBCD5F6C3B1CDF0A@DM4PR12MB6158.namprd12.prod.outlook.com/

-- 
மணிவண்ணன் சதாசிவம்

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

[Havalige, Thippeswamy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Mani,

> -----Original Message-----
> From: mani@kernel.org <mani@kernel.org>
> Sent: Wednesday, October 22, 2025 3:25 PM
> To: Stefan Roese <stefan.roese@mailbox.org>
> Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> <ravib@amazon.com>; Havalige, Thippeswamy
> <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> bhelgaas@google.com; linux-pci@vger.kernel.org; kwilczynski@kernel.org;
> robh@kernel.org; Simek, Michal <michal.simek@amd.com>; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> stable@vger.kernel.org; Sean Anderson <sean.anderson@linux.dev>
> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>
> On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> > Hi Bjorn,
> > Hi Ravi,
> >
> > On 10/21/25 23:28, Bjorn Helgaas wrote:
> > > On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > > > > 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@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
> > > > > > > > [...]
> >
> > First a comment on this IRQ logging:
> >
> > These lines do NOT refer to the INTx IRQ(s) but the controller
> > internal "events" (errors etc). Please see this log for INTx on my
> > Versal platform with pci_irqd_intx_xlate added:
> >
> >  24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> >  25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> >  26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> >  27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> >  28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> >  29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> >  30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> >  31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> >  32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> >  33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> >  34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> >  35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> >  36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> >  37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> >  38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> >  39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> >
> > The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
> > Event').
> >
> > More below...
> >
> > > > > > > >
> > > > > > > > Changes since v1::
> > > > > > > > - Fixed commit message per reviewer's comments
> > > > > > > >
> > > > > > > > Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA
> > > > > > > > Root Port driver")
> > > > > > > > Cc: stable@vger.kernel.org
> > > > > > > > Signed-off-by: Ravi Kumar Bandi <ravib@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.roe
> > > > > > > se@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.
> > >
> > > OK, I'll assume the interrupts happened but the driver might not
> > > have been able to handle them correctly, e.g., it was prepared for
> > > INTA but got INTB or similar.
> > >
> > > > >   - 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.
> > >
> > > Stefan clarified in a private message that he had applied your patch
> > > first, so this mystery is solved.
> >
> > Yes. I applied Ravi's patch first and still got no INTx delivered to
> > the nvme driver. That's what me triggered to dig deeper here and
> > resulted in this v2 patch with pci_irqd_intx_xlate added.
> >
> > BTW:
> > I re-tested just now w/o Ravi's patch and the INTx worked. Still I
> > think Ravi's patch is valid and should be applied...
>
> How come INTx is working without the patch from Ravi which enabled INTx
> routing in the controller? Was it enabled by default in the hardware?

Can you please cross-check the interrupt-map property in the device tree? Currently, the driver isn’t translating (pci_irqd_intx_xlate) the INTx number.

Here’s required DT property:

interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
                <0 0 0 2 &pcie_intc_0 1>,
                <0 0 0 3 &pcie_intc_0 2>,
                <0 0 0 4 &pcie_intc_0 3>;
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்

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

[Havalige, Thippeswamy]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Mani,

> -----Original Message-----
> From: Havalige, Thippeswamy
> Sent: Wednesday, October 22, 2025 3:34 PM
> To: 'mani@kernel.org' <mani@kernel.org>; Stefan Roese
> <stefan.roese@mailbox.org>
> Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> <ravib@amazon.com>; lpieralisi@kernel.org; bhelgaas@google.com; linux-
> pci@vger.kernel.org; kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> <sean.anderson@linux.dev>; Yeleswarapu, Nagaradhesh
> <nagaradhesh.yeleswarapu@amd.com>
> Subject: RE: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>
> Hi Mani,
>
> > -----Original Message-----
> > From: mani@kernel.org <mani@kernel.org>
> > Sent: Wednesday, October 22, 2025 3:25 PM
> > To: Stefan Roese <stefan.roese@mailbox.org>
> > Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> > <ravib@amazon.com>; Havalige, Thippeswamy
> > <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> > bhelgaas@google.com; linux-pci@vger.kernel.org;
> > kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> > <michal.simek@amd.com>; linux-arm- kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> > <sean.anderson@linux.dev>
> > Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> >
> > On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> > > Hi Bjorn,
> > > Hi Ravi,
> > >
> > > On 10/21/25 23:28, Bjorn Helgaas wrote:
> > > > On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> > > > > > 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@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
> > > > > > > > > [...]
> > >
> > > First a comment on this IRQ logging:
> > >
> > > These lines do NOT refer to the INTx IRQ(s) but the controller
> > > internal "events" (errors etc). Please see this log for INTx on my
> > > Versal platform with pci_irqd_intx_xlate added:
> > >
> > >  24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> > >  25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> > >  26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> > >  27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> > >  28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> > >  29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> > >  30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> > >  31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> > >  32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> > >  33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> > >  34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> > >  35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> > >  36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> > >  37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> > >  38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> > >  39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> > >
> > > The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
> > > Event').
> > >
> > > More below...
> > >
> > > > > > > > >
> > > > > > > > > Changes since v1::
> > > > > > > > > - Fixed commit message per reviewer's comments
> > > > > > > > >
> > > > > > > > > Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA
> > > > > > > > > Root Port driver")
> > > > > > > > > Cc: stable@vger.kernel.org
> > > > > > > > > Signed-off-by: Ravi Kumar Bandi <ravib@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.r
> > > > > > > > oe
> > > > > > > > se@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.
> > > >
> > > > OK, I'll assume the interrupts happened but the driver might not
> > > > have been able to handle them correctly, e.g., it was prepared for
> > > > INTA but got INTB or similar.
> > > >
> > > > > >   - 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.
> > > >
> > > > Stefan clarified in a private message that he had applied your
> > > > patch first, so this mystery is solved.
> > >
> > > Yes. I applied Ravi's patch first and still got no INTx delivered to
> > > the nvme driver. That's what me triggered to dig deeper here and
> > > resulted in this v2 patch with pci_irqd_intx_xlate added.


Xlate should not be added instead of it dt needs to be updated as below.

> > >
> > > BTW:
> > > I re-tested just now w/o Ravi's patch and the INTx worked. Still I
> > > think Ravi's patch is valid and should be applied...
> >
> > How come INTx is working without the patch from Ravi which enabled
> > INTx routing in the controller? Was it enabled by default in the hardware?
>
> Can you please cross-check the interrupt-map property in the device tree?
> Currently, the driver isn’t translating (pci_irqd_intx_xlate) the INTx number.
>
> Here’s required DT property:
>
> interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
>                 <0 0 0 2 &pcie_intc_0 1>,
>                 <0 0 0 3 &pcie_intc_0 2>,
>                 <0 0 0 4 &pcie_intc_0 3>;
> >
> > - Mani
> >
> > --
> > மணிவண்ணன் சதாசிவம்

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

[Stefan Roese]

On 10/22/25 12:04, Havalige, Thippeswamy wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> Hi Mani,
> 
>> -----Original Message-----
>> From: mani@kernel.org <mani@kernel.org>
>> Sent: Wednesday, October 22, 2025 3:25 PM
>> To: Stefan Roese <stefan.roese@mailbox.org>
>> Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
>> <ravib@amazon.com>; Havalige, Thippeswamy
>> <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
>> bhelgaas@google.com; linux-pci@vger.kernel.org; kwilczynski@kernel.org;
>> robh@kernel.org; Simek, Michal <michal.simek@amd.com>; linux-arm-
>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>> stable@vger.kernel.org; Sean Anderson <sean.anderson@linux.dev>
>> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>>
>> On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
>>> Hi Bjorn,
>>> Hi Ravi,
>>>
>>> On 10/21/25 23:28, Bjorn Helgaas wrote:
>>>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
>>>>>> 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@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
>>>>>>>>> [...]
>>>
>>> First a comment on this IRQ logging:
>>>
>>> These lines do NOT refer to the INTx IRQ(s) but the controller
>>> internal "events" (errors etc). Please see this log for INTx on my
>>> Versal platform with pci_irqd_intx_xlate added:
>>>
>>>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
>>>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
>>>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
>>>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
>>>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
>>>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
>>>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
>>>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
>>>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
>>>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
>>>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
>>>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
>>>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
>>>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
>>>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
>>>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
>>>
>>> The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
>>> Event').
>>>
>>> More below...
>>>
>>>>>>>>>
>>>>>>>>> Changes since v1::
>>>>>>>>> - Fixed commit message per reviewer's comments
>>>>>>>>>
>>>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA
>>>>>>>>> Root Port driver")
>>>>>>>>> Cc: stable@vger.kernel.org
>>>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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.roe
>>>>>>>> se@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.
>>>>
>>>> OK, I'll assume the interrupts happened but the driver might not
>>>> have been able to handle them correctly, e.g., it was prepared for
>>>> INTA but got INTB or similar.
>>>>
>>>>>>    - 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.
>>>>
>>>> Stefan clarified in a private message that he had applied your patch
>>>> first, so this mystery is solved.
>>>
>>> Yes. I applied Ravi's patch first and still got no INTx delivered to
>>> the nvme driver. That's what me triggered to dig deeper here and
>>> resulted in this v2 patch with pci_irqd_intx_xlate added.
>>>
>>> BTW:
>>> I re-tested just now w/o Ravi's patch and the INTx worked. Still I
>>> think Ravi's patch is valid and should be applied...
>>
>> How come INTx is working without the patch from Ravi which enabled INTx
>> routing in the controller? Was it enabled by default in the hardware?
> 
> Can you please cross-check the interrupt-map property in the device tree? Currently, the driver isn’t translating (pci_irqd_intx_xlate) the INTx number.
> 
> Here’s required DT property:
> 
> interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
>                  <0 0 0 2 &pcie_intc_0 1>,
>                  <0 0 0 3 &pcie_intc_0 2>,
>                  <0 0 0 4 &pcie_intc_0 3>;

Here the auto-generated DT property (Vivado 2025.1) for our design:

         interrupt-map = <0 0 0 1 &psv_pcie_intc_0 1>,
                         <0 0 0 2 &psv_pcie_intc_0 2>,
                         <0 0 0 3 &psv_pcie_intc_0 3>,
                         <0 0 0 4 &psv_pcie_intc_0 4>;

So we should manually "fix" the auto-generated DT instead? I would
rather like to skip such a step, as this is error prone with frequent
updates from the FPGA bistream design.

Thanks,
Stefan

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

[Havalige, Thippeswamy]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Stefan Roese <stefan.roese@mailbox.org>
> Sent: Wednesday, October 22, 2025 3:41 PM
> To: Havalige, Thippeswamy <thippeswamy.havalige@amd.com>;
> mani@kernel.org
> Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> <ravib@amazon.com>; lpieralisi@kernel.org; bhelgaas@google.com; linux-
> pci@vger.kernel.org; kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> <sean.anderson@linux.dev>; Yeleswarapu, Nagaradhesh
> <nagaradhesh.yeleswarapu@amd.com>
> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
>
> On 10/22/25 12:04, Havalige, Thippeswamy wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > Hi Mani,
> >
> >> -----Original Message-----
> >> From: mani@kernel.org <mani@kernel.org>
> >> Sent: Wednesday, October 22, 2025 3:25 PM
> >> To: Stefan Roese <stefan.roese@mailbox.org>
> >> Cc: Bjorn Helgaas <helgaas@kernel.org>; Bandi, Ravi Kumar
> >> <ravib@amazon.com>; Havalige, Thippeswamy
> >> <thippeswamy.havalige@amd.com>; lpieralisi@kernel.org;
> >> bhelgaas@google.com; linux-pci@vger.kernel.org;
> >> kwilczynski@kernel.org; robh@kernel.org; Simek, Michal
> >> <michal.simek@amd.com>; linux-arm- kernel@lists.infradead.org;
> >> linux-kernel@vger.kernel.org; stable@vger.kernel.org; Sean Anderson
> >> <sean.anderson@linux.dev>
> >> Subject: Re: [PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts
> >>
> >> On Wed, Oct 22, 2025 at 08:59:19AM +0200, Stefan Roese wrote:
> >>> Hi Bjorn,
> >>> Hi Ravi,
> >>>
> >>> On 10/21/25 23:28, Bjorn Helgaas wrote:
> >>>> On Tue, Oct 21, 2025 at 08:55:41PM +0000, Bandi, Ravi Kumar wrote:
> >>>>>> 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@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
> >>>>>>>>> [...]
> >>>
> >>> First a comment on this IRQ logging:
> >>>
> >>> These lines do NOT refer to the INTx IRQ(s) but the controller
> >>> internal "events" (errors etc). Please see this log for INTx on my
> >>> Versal platform with pci_irqd_intx_xlate added:
> >>>
> >>>   24:          0          0  pl_dma:RC-Event   0 Level     LINK_DOWN
> >>>   25:          0          0  pl_dma:RC-Event   3 Level     HOT_RESET
> >>>   26:          0          0  pl_dma:RC-Event   8 Level     CFG_TIMEOUT
> >>>   27:          0          0  pl_dma:RC-Event   9 Level     CORRECTABLE
> >>>   28:          0          0  pl_dma:RC-Event  10 Level     NONFATAL
> >>>   29:          0          0  pl_dma:RC-Event  11 Level     FATAL
> >>>   30:          0          0  pl_dma:RC-Event  20 Level     SLV_UNSUPP
> >>>   31:          0          0  pl_dma:RC-Event  21 Level     SLV_UNEXP
> >>>   32:          0          0  pl_dma:RC-Event  22 Level     SLV_COMPL
> >>>   33:          0          0  pl_dma:RC-Event  23 Level     SLV_ERRP
> >>>   34:          0          0  pl_dma:RC-Event  24 Level     SLV_CMPABT
> >>>   35:          0          0  pl_dma:RC-Event  25 Level     SLV_ILLBUR
> >>>   36:          0          0  pl_dma:RC-Event  26 Level     MST_DECERR
> >>>   37:          0          0  pl_dma:RC-Event  27 Level     MST_SLVERR
> >>>   38:         94          0  pl_dma:RC-Event  16 Level     84000000.axi-pcie
> >>>   39:         94          0  pl_dma:INTx   0 Level     nvme0q0, nvme0q1
> >>>
> >>> The last line shows the INTx IRQs here ('pl_dma:INTx' vs 'pl_dma:RC-
> >>> Event').
> >>>
> >>> More below...
> >>>
> >>>>>>>>>
> >>>>>>>>> Changes since v1::
> >>>>>>>>> - Fixed commit message per reviewer's comments
> >>>>>>>>>
> >>>>>>>>> Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root
> >>>>>>>>> Port driver")
> >>>>>>>>> Cc: stable@vger.kernel.org
> >>>>>>>>> Signed-off-by: Ravi Kumar Bandi <ravib@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.roe
> >>>>>>>> se@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.
> >>>>
> >>>> OK, I'll assume the interrupts happened but the driver might not
> >>>> have been able to handle them correctly, e.g., it was prepared for
> >>>> INTA but got INTB or similar.
> >>>>
> >>>>>>    - 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.
> >>>>
> >>>> Stefan clarified in a private message that he had applied your
> >>>> patch first, so this mystery is solved.
> >>>
> >>> Yes. I applied Ravi's patch first and still got no INTx delivered to
> >>> the nvme driver. That's what me triggered to dig deeper here and
> >>> resulted in this v2 patch with pci_irqd_intx_xlate added.
> >>>
> >>> BTW:
> >>> I re-tested just now w/o Ravi's patch and the INTx worked. Still I
> >>> think Ravi's patch is valid and should be applied...
> >>
> >> How come INTx is working without the patch from Ravi which enabled
> >> INTx routing in the controller? Was it enabled by default in the hardware?
> >
> > Can you please cross-check the interrupt-map property in the device tree?
> Currently, the driver isn’t translating (pci_irqd_intx_xlate) the INTx number.
> >
> > Here’s required DT property:
> >
> > interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
> >                  <0 0 0 2 &pcie_intc_0 1>,
> >                  <0 0 0 3 &pcie_intc_0 2>,
> >                  <0 0 0 4 &pcie_intc_0 3>;
>
> Here the auto-generated DT property (Vivado 2025.1) for our design:
>
>          interrupt-map = <0 0 0 1 &psv_pcie_intc_0 1>,
>                          <0 0 0 2 &psv_pcie_intc_0 2>,
>                          <0 0 0 3 &psv_pcie_intc_0 3>,
>                          <0 0 0 4 &psv_pcie_intc_0 4>;
>
> So we should manually "fix" the auto-generated DT instead? I would rather like
> to skip such a step, as this is error prone with frequent updates from the FPGA
> bistream design.
Yes, you need to manually fix this auto-generated DT for now. Will take this discussion offline.
>
> Thanks,
> Stefan