[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3ac0d6c5-0c49-45fd-b855-d9b040249096@rock-chips.com>
Date: Fri, 21 Nov 2025 12:04:09 +0800
From: Shawn Lin <shawn.lin@...k-chips.com>
To: Manivannan Sadhasivam <mani@...nel.org>,
Qiang Yu <qiang.yu@....qualcomm.com>
Cc: shawn.lin@...k-chips.com, Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczyński <kwilczynski@...nel.org>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Jingoo Han <jingoohan1@...il.com>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 3/5] PCI: dwc: Remove MSI/MSIX capability if iMSI-RX is
used as MSI controller
在 2025/11/21 星期五 1:00, Manivannan Sadhasivam 写道:
> On Thu, Nov 20, 2025 at 10:06:03PM +0800, Shawn Lin wrote:
>> 在 2025/11/10 星期一 14:59, Qiang Yu 写道:
>>> Some platforms may not support ITS (Interrupt Translation Service) and
>>> MBI (Message Based Interrupt), or there are not enough available empty SPI
>>> lines for MBI, in which case the msi-map and msi-parent property will not
>>> be provided in device tree node. For those cases, the DWC PCIe driver
>>> defaults to using the iMSI-RX module as MSI controller. However, due to
>>> DWC IP design, iMSI-RX cannot generate MSI interrupts for Root Ports even
>>> when MSI is properly configured and supported as iMSI-RX will only monitor
>>> and intercept incoming MSI TLPs from PCIe link, but the memory write
>>> generated by Root Port are internal system bus transactions instead of
>>> PCIe TLPs, so they are ignored.
>>>
>>> This leads to interrupts such as PME, AER from the Root Port not received
>>
>> This's true which also stops Rockchip's dwc IP from working with AER
>> service. But my platform can't work with AER service even with ITS support.
>>
>>> on the host and the users have to resort to workarounds such as passing
>>> "pcie_pme=nomsi" cmdline parameter.
>>
>> ack.
>>
>>>
>>> To ensure reliable interrupt handling, remove MSI and MSI-X capabilities
>>> from Root Ports when using iMSI-RX as MSI controller, which is indicated
>>> by has_msi_ctrl == true. This forces a fallback to INTx interrupts,
>>> eliminating the need for manual kernel command line workarounds.
>>>
>>> With this behavior:
>>> - Platforms with ITS/MBI support use ITS/MBI MSI for interrupts from all
>>> components.
>>> - Platforms without ITS/MBI support fall back to INTx for Root Ports and
>>> use iMSI-RX for other PCI devices.
>>>
>>> Signed-off-by: Qiang Yu <qiang.yu@....qualcomm.com>
>>> ---
>>> drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
>>> index 20c9333bcb1c4812e2fd96047a49944574df1e6f..3724aa7f9b356bfba33a6515e2c62a3170aef1e9 100644
>>> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
>>> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
>>> @@ -1083,6 +1083,16 @@ int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
>>> dw_pcie_dbi_ro_wr_dis(pci);
>>> + /*
>>> + * If iMSI-RX module is used as the MSI controller, remove MSI and
>>> + * MSI-X capabilities from PCIe Root Ports to ensure fallback to INTx
>>> + * interrupt handling.
>>> + */
>>> + if (pp->has_msi_ctrl) {
>>
>> Isn't has_msi_ctrl means you have something like GIC-ITS
>> support instead of iMSI module? Am I missing anything?
>>
>
> It is the other way around. Presence of this flag means, iMSI-RX is used. But I
> think the driver should clear the CAPs irrespective of this flag.
Thanks for correcting me. Yeap, how can I make such a mistake. :(
Anyway, this patch works for me:
root@...ian:/userdata# ./aer-inject aer.txt
[ 17.764272] pcieport 0000:00:00.0: aer_inject: Injecting errors
00000040/00000000 into device 0000:01:00.0
[ 17.765178] aer_isr ! #log I added in aer_isr
[ 17.765394] pcieport 0000:00:00.0: AER: Correctable error message
received from 0000:01:00.0
[ 17.766211] nvme 0000:01:00.0: PCIe Bus Error: severity=Correctable,
type=Data Link Layer, (Receiver ID)
root@...ian:/userdata# [ 17.767045] nvme 0000:01:00.0: device
[144d:a80a] error status/mask=00000040/0000e000
[ 17.767980] nvme 0000:01:00.0: [ 6] BadTLP
root@...ian:/userdata# cat /proc/interrupts | grep aerdrv
60: 0 0 0 0 0 0 0 0 INTx 0
Edge PCIe PME, aerdrv, PCIe bwctrl
63: 0 0 0 1 0 0 0 0 INTx 0
Edge PCIe PME, aerdrv
110: 0 0 0 0 0 0 0 0 INTx 0
Edge PCIe PME, aerdrv
>
>>> + dw_pcie_remove_capability(pci, PCI_CAP_ID_MSI);
>>> + dw_pcie_remove_capability(pci, PCI_CAP_ID_MSIX);
>>
>> Will it make all devices connected to use INTx only?
>>
>
> Nah, it is just for the Root Port. The MSI/MSI-X from endpoint devices will
> continue to work as usual.
Qiang Yu,
Could you please help your IP version with below patch?
It's in hex format, you could convert each pair of hex
characters to ASCII, i.g, 0x3437302a is 4.70a. The reason
is we asked Synopsys to help check this issue before, then
we were informed that they have supported it at least since
IP version 6.0x. So we may have to limit the version first.
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -1057,6 +1057,10 @@ int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
dw_pcie_msi_init(pp);
+#define PORT_LOGIC_PCIE_VERSION_NUMBER_OFF 0x8f8
+ val = dw_pcie_readl_dbi(pci, PORT_LOGIC_PCIE_VERSION_NUMBER_OFF);
+ printk("version = 0x%x\n", val);
+
Powered by blists - more mailing lists