From: Niklas Cassel <cassel@kernel.org>
To: Shawn Lin <shawn.lin@rock-chips.com>,
Manivannan Sadhasivam <mani@kernel.org>
Cc: "Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>,
"Jingoo Han" <jingoohan1@gmail.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Frank Li" <Frank.Li@nxp.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Koichiro Den" <den@valinux.co.jp>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: dwc: ep: Cache MSI outbound iATU mapping
Date: Mon, 5 Jan 2026 12:06:37 +0100 [thread overview]
Message-ID: <aVubPUphGP59bH09@ryzen> (raw)
In-Reply-To: <424133b7-bd6b-4602-96ea-4413ce4f985d@rock-chips.com>
Hello all,
On Tue, Dec 23, 2025 at 02:23:39PM +0800, Shawn Lin wrote:
> > > I checked the IP configurtion parameters for RK3588 DM controller for
> > > sure, it sets MSIX_TABLE_EN=1.
> > >
> > > Looking into dw_pcie_ep_raise_msix_irq_doorbell(), it doesn't seem to
> > > match the dwc databook. No matter for non-AXI mode or AXI access mode,
> > > shouldn't we need to generate a MSI-X table RAM with data/address/
> > > vector/TC in advanced? Am I missing anything because I didn't look
> > The MSI-X table will updated automatically when host updates the MSI-X
> > table, when MSI-X is enabled
> > by host.
>
> Thanks for these details.
> I re-read the databook, especially "Figure 3-49 iMSIX-TX: MSIX
> Transmit ". Yes, it's updated automatically when host write access
> it, which either comes from RX or local DBI(for debug purpose).
With the help of Shawn, I managed to get dw_pcie_ep_raise_msix_irq_doorbell()
to work on RK3588.
By default, on RK3588, the MSI-X table is stored in BAR4 at offset 0x4000.
There seems to be a limitation that the iMSIX-TX doorbell feature only
works when the MSI-X table is stored in this default location.
As you know, by default, pci-epf-test stores the MSI-X table in BAR0,
after the registers defined by pci-epf-test itself.
This works fine when triggering a MSI-X using dw_pcie_ep_raise_msix_irq(),
but does not work when using dw_pcie_ep_raise_msix_irq_doorbell() (at least
not or RK3588).
Additionally, on RK3588, at offset 0x0 in BAR4, the eDMA registers are
mapped, so we cannot simply use BAR4 as test_reg_bar, as that would conflict
with the registers defined by pci-epf-test-itself.
The solution here is most likely to let EPC drivers define a
"HW limitation" of the MSI-X table (BAR number and offset), and create a new
API in the PCI endpoint framework that exposes this, and modify all EPF
drivers to use this API before calling pci_epc_set_msix().
Personally, I'm too busy to work on this right now.
For our use case with the NVMe PCI EPF, we can simply force it to only
use MSI (instead of MSI-X).
But... I could submit a WARN() in dw_pcie_ep_raise_msix_irq() that explains
that this function is broken, and that dw_pcie_ep_raise_msix_irq_doorbell()
should be used instead, on platforms that support it.
Or, if it is preferred, we could simply modify all DWC based drivers that is
not using dw_pcie_ep_raise_msix_irq_doorbell() (i.e. all except layerspace)
to simply not set "msix_capable = true" in epc_features, as we know that all
drivers that are using dw_pcie_ep_raise_msix_irq() are broken.
Thoughts?
Kind regards,
Niklas
next prev parent reply other threads:[~2026-01-05 11:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 7:13 [PATCH] PCI: dwc: ep: Cache MSI outbound iATU mapping Niklas Cassel
2025-12-22 8:19 ` Krishna Chaitanya Chundru
2025-12-22 8:36 ` Niklas Cassel
2025-12-22 8:42 ` Krishna Chaitanya Chundru
2025-12-22 8:49 ` Niklas Cassel
2025-12-22 9:58 ` Manivannan Sadhasivam
2025-12-22 10:42 ` Niklas Cassel
2025-12-22 11:11 ` Niklas Cassel
2025-12-22 11:19 ` Manivannan Sadhasivam
2025-12-22 12:23 ` Krishna Chaitanya Chundru
2025-12-22 13:00 ` Niklas Cassel
2025-12-23 1:12 ` Shawn Lin
2025-12-23 4:35 ` Krishna Chaitanya Chundru
2025-12-23 6:23 ` Shawn Lin
2025-12-23 7:12 ` Niklas Cassel
2026-01-05 11:06 ` Niklas Cassel [this message]
2026-01-06 1:37 ` Shawn Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aVubPUphGP59bH09@ryzen \
--to=cassel@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=bhelgaas@google.com \
--cc=den@valinux.co.jp \
--cc=dlemoal@kernel.org \
--cc=jingoohan1@gmail.com \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=kwilczynski@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.