Re: [PATCH v6 0/8] PCI: endpoint: pci-ep-msi: Add embedded doorbell fallback

[Niklas Cassel <cassel@kernel.org>]

On Thu, Feb 12, 2026 at 12:57:52AM +0900, Koichiro Den wrote:
> Could you try a quick experiment on the Rock 5B EP side?
> 
>   devmem 0xa403800a0 32 1
>   devmem 0xa403800a0 32 2
>   devmem 0xa403800a0 32 4
>   devmem 0xa403800a0 32 8

Here it goes:

# cat /proc/interrupts | grep edma
 53:          0          0          0          0          0          0          0          0    GICv3 303 Level     dw-edma-core:a40000000.pcie-ep, pci-ep-test-doorbell
 54:          0          0          0          0          0          0          0          0    GICv3 304 Level     dw-edma-core:a40000000.pcie-ep
 55:          0          0          0          0          0          0          0          0    GICv3 301 Level     dw-edma-core:a40000000.pcie-ep
 56:          0          0          0          0          0          0          0          0    GICv3 302 Level     dw-edma-core:a40000000.pcie-ep
# devmem 0xa403800a0 32 1
# cat /proc/interrupts | grep edma
 53:          0          0          0          0          0          0          0          0    GICv3 303 Level     dw-edma-core:a40000000.pcie-ep, pci-ep-test-doorbell
 54:          1          0          0          0          0          0          0          0    GICv3 304 Level     dw-edma-core:a40000000.pcie-ep
 55:          0          0          0          0          0          0          0          0    GICv3 301 Level     dw-edma-core:a40000000.pcie-ep
 56:          0          0          0          0          0          0          0          0    GICv3 302 Level     dw-edma-core:a40000000.pcie-ep
# devmem 0xa403800a0 32 1
# cat /proc/interrupts | grep edma
 53:          0          0          0          0          0          0          0          0    GICv3 303 Level     dw-edma-core:a40000000.pcie-ep, pci-ep-test-doorbell
 54:          2          0          0          0          0          0          0          0    GICv3 304 Level     dw-edma-core:a40000000.pcie-ep
 55:          0          0          0          0          0          0          0          0    GICv3 301 Level     dw-edma-core:a40000000.pcie-ep
 56:          0          0          0          0          0          0          0          0    GICv3 302 Level     dw-edma-core:a40000000.pcie-ep
# devmem 0xa403800a0 32 1
[  104.217632] pci_epf_test_doorbell_primary
# cat /proc/interrupts | grep edma
 53:          1          0          0          0          0          0          0          0    GICv3 303 Level     dw-edma-core:a40000000.pcie-ep, pci-ep-test-doorbell
 54:          2          0          0          0          0          0          0          0    GICv3 304 Level     dw-edma-core:a40000000.pcie-ep
 55:          0          0          0          0          0          0          0          0    GICv3 301 Level     dw-edma-core:a40000000.pcie-ep
 56:          0          0          0          0          0          0          0          0    GICv3 302 Level     dw-edma-core:a40000000.pcie-ep
# devmem 0xa403800a0 32 1
# cat /proc/interrupts | grep edma
 53:          1          0          0          0          0          0          0          0    GICv3 303 Level     dw-edma-core:a40000000.pcie-ep, pci-ep-test-doorbell
 54:          2          0          0          0          0          0          0          0    GICv3 304 Level     dw-edma-core:a40000000.pcie-ep
 55:          1          0          0          0          0          0          0          0    GICv3 301 Level     dw-edma-core:a40000000.pcie-ep
 56:          0          0          0          0          0          0          0          0    GICv3 302 Level     dw-edma-core:a40000000.pcie-ep


Seems very random if you ask me.

Same randomness is observed when I write other values, e.g. 2.


Could this randomness be because I do not have:
https://lore.kernel.org/dmaengine/20260105075904.1254012-1-den@valinux.co.jp/

Or do you think that is completely unrelated?



> > RK3588 (pcie-dw-rockchip.c) exposes the DMA registers in BAR4 by default.
> > If I hack pci-epf-test on top of your patch to unconditionally return BAR4 with
> > offset 0xa0, it works. So my best guess is that the fixed inbound translation
> > in BAR4 (to the eDMA registers) somehow messes with the inbound translation if
> > another BAR tries to use an inbound translation to the eDMA registers as well.

Adding Manikanta to CC.

RK3588 is not the only SoC that has the eDMA registers exposed via a BAR,
some other SoCs like Tegra234 also has the eDMA registers exposed via a BAR.

Me and Manikanta were discussing this a few days ago:
https://lore.kernel.org/linux-pci/aYsQu9lQi4IzfBiP@ryzen/


> 
> Thanks a lot for letting me know that. I see two possible ways forward:
> 
>   (a) extend PCI_EPC_AUX_DMA_CTRL_MMIO to optionally describe that the DMA
>       MMIO window is already mapped to a fixed BAR and should be reused, so
>       EPFs avoid creating a second mapping to the same target. I guess it
>       could be treated as a quirk for "rockchip,rk3588-pcie-ep".

I do like the idea that an EPC driver can somehow provide the BAR number
which the eDMA registers are already exposed in, together with the offset
and the size within that BAR. After that pci-epf-test could still work with
the emulated doorbell (only difference is that it would not program the iATU).

(This would also require Manikanta suggestion of having both a BAR_RESERVED and
a BAR_DISABLED type, and support in pci_endpoint_test to ignore RESERVED BARs.)


> 
>   (b) alternatively, clear the default BAR4 mapping on RK3588 at least
>       temporarily when using the pci-epf-msi doorbell fallback.

So for these SoCs like RK3588 and Tegra234, it appears that the option to
expose the eDMA registers in one of the BARs is a Synopsys DWC config that
you set when you synthesize the DWC core.
When you do this, it appear that that BAR will always some kind of fixed
inbound address translation (i.e. even when you disable all inbound iATUs
this translation for BAR4 to eDMA registers is still there).


Kind regards,
Niklas