Re: [PATCH] PCI: dwc: ep: Cache MSI outbound iATU mapping

[Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>]

On 12/22/2025 4:41 PM, Niklas Cassel wrote:
> On Mon, Dec 22, 2025 at 03:28:30PM +0530, Manivannan Sadhasivam wrote:
>>> Use the MSIX doorbell method which will not use iATU at all,
>>> dw_pcie_ep_raise_msix_irq_doorbell().
>>>
>> I think this is the safe bet since this feature doesn't seem like an optional
>> one.
>>
>> Niklas, if you can just fix MSI in this patch and leave out MSI-X for the vendor
>> drivers to transition to doorbell, I'm OK to merge it. Otherwise, I don't know
>> how you can reliably fix MSI-X generation with AXI slave interface.
> FWIW, I did try to simply change:
>
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index 8f2cc1ef25e3..00770f9786e3 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -319,7 +319,8 @@ static int rockchip_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
>          case PCI_IRQ_MSI:
>                  return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
>          case PCI_IRQ_MSIX:
> -               return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num);
> +               return dw_pcie_ep_raise_msix_irq_doorbell(ep, func_no,
> +                                                         interrupt_num);
>          default:
>                  dev_err(pci->dev, "UNKNOWN IRQ type\n");
>          }
>
>
> For the pcie-dw-rockchip driver, but it is not working:
> [  130.042849] nvme nvme0: I/O tag 0 (1000) QID 0 timeout, completion polled
>
> Without this change, things work.
>
> Perhaps this feature is not an optional one, but at least we will require
> more changes than a simple one liner.
Hi Niklas,

It should be automatic only, no extra configurations should be required, 
I believe your
HW doesn't support this feature, from spec 6..0a, sec 3.9.1.3 iMSIX-TX: 
Integrated MSI-X Transmit (USP)
I believe your HW is not generated with MSIX_TABLE_EN =1. In that case 
you can't use this feature.

or
Are using VF for NVMe, in that MSIX doorbell logic needs to be updated 
for VF's also.

There is one more option to use MSIX with out using iATU i.e MSIX 
address match mode
taken from same section above this also, but it is not clear to me if 
this feature also depends
on MSIX_TABLE_EN=1. May be give it try once.

"Automatic triggering of MSI-X generation when your application issues a 
MWr at the
AXI subordi nate interface with an address equal to 
MSIX_ADDRESS_MATCH_LOW_OFF
and MSIX_ADDRESS_ MATCH_HIGH_OFF.
     ❑ MWr must be DWORD-aligned and must contain MSI-X vector, TC, and 
function number.

■ When your local application issues an MWr on the AXI subordinate 
interface to a specific address
(MSIX_ADDRESS_MATCH_LOW_OFF), the controller extracts the vector and TC 
information from the
MWr payload and creates the MSI-X request.

■ AXI bridge guarantees ordering coherency by forwarding the MSI-X 
request after the preceding MWr has been transmitted.

■ Processes one MSI-X request at a time and halts subordinate access if 
a second MSI-X request is submitted before first one is complete"

we can allocated a address and write in this MSIX Address match register 
at probe and update that address with the vector
number and function number etc(Same as how we write in MSIX doorbell 
register) when we want to send the msix.

- Krishna Chaitanya.
>
>
> Kind regards,
> Niklas