On Wed, Feb 11, 2026 at 05:52:53PM +0100, Niklas Cassel wrote: > 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.
Thanks for the testing and sharing the actual behavior. That helps a lot. > > > Could this randomness be because I do not have: > https://lore.kernel.org/dmaengine/[email protected]/ > > Or do you think that is completely unrelated? I didn't clearly answer this in my previous response, apologies. I believe that patch is unrelated. It addresses MSI data handling for multi-vector IMWr generation (i.e. remote interrupts), whereas here we are dealing with the emulated interrupt path for the embedded doorbell. If applying that patch changes the emulated interrupt behavior in your environment, please let me know. That would be very interesting. > > > > > > 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.) Thanks for the additional context. Even if we introduce the distinction between BAR_RESERVED and BAR_DISABLED, as I understand it, we currently lack a way to describe what actually resides behind a BAR_RESERVED region. Perhaps extending pci_epc_bar_desc to describe what a reserved BAR contains (e.g. DMA register block) might allow us to handle this in a cleaner and more generic way. It would at least be cleaner than treating it as a quirk and hard-code the reserved BAR+offset+contents. > > > > > > (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). Thanks a lot for this input, so (b) would not be viable from the beginning. Best regards, Koichiro > > > Kind regards, > Niklas
