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/[email protected]/ 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
