Re: [PATCH v2] pci: designware: Set DMA_BYPASS bit in outbound IATU CTRL2 register

[Niklas Cassel <cassel@kernel.org>]

On Tue, Oct 13, 2026 at 10:48:37PM +0530, Manivannan Sadhasivam wrote:
> On 2026-09-13 19:16 +0200, Niklas Cassel wrote:
> > 
> > Without the patch in $subject, on a DWC based platform:
> > 
> > pci_epc_mem_map() will setup an iATU entry, and the eDMA transaction will then
> > be translated using that iATU entry, before being sent out on the PCIe bus.
> > 
> 
> No, that's not true. While the pci_epc_mem_map() does setup an iATU entry, eDMA
> transaction doesn't use the mapped address.
> 
> If you look into the eDMA read path:
> 	pci_epc_mem_map()
> 		-> Allocates map.phys_addr and sets up an iATU entry
> 	pci_epf_test_data_transfer()
> 		-> dma_local points to address allocated by dma_map_single()
> 		   (dma_dst)
> 		-> dma_remote points to RC address referenced in src_addr
> 		-> These two were passed to dmaengine_prep_config_single()
> 		   ignoring the map.phys_addr passed through dma_src parameter.
> 
> For eDMA write:
> 	pci_epc_mem_map()
> 		-> Allocates map.phys_addr and sets up an iATU entry
> 	pci_epf_test_data_transfer()
> 		-> dma_local points to address allocated by dma_map_single()
> 		   (dma_src)
> 		-> dma_remote points to RC address referenced in dst_addr
> 		-> These two were passed to dmaengine_prep_config_single()
> 		   ignoring the map.phys_addr passed through dma_dst parameter.
> 
> So essentially, the address used by the eDMA is the raw RC PCIe address, not
> translated by the iATU. In fact, the Designware Databook also doesn't recommend
> setting up the iATU entry for the eDMA path. So the allocated iATU entry is
> useless.

I see, you are correct.
The pci-epf-test.c driver is very misleading, because if does:

    ...
    pci_epc_mem_map();

    if (flags & FLAG_USE_DMA) {
        dma_map_single();
        pci_epf_test_data_transfer();
    } else {
        memcpy_fromio();
    }

    pci_epc_mem_unmap();


This suggests to the reader that the mapping is used in both cases...
Why else would the mapping be done unconditionally?

I strongly suggest that the pci_epc_mem_map() and pci_epc_mem_unmap()
calls are moved into the "else" clause then.

Since this patch is already touching behavior related to this, it would be
nice if the patch author could also write a patch that cleans up this mess.


> 
> But the issue this patch is trying to address is, if the raw PCI address or the
> dma_map_single address used by the eDMA happens to be present in one of the
> existing iATU mappings, then at that point, the address can get translated
> causing wrong address to be sent over the bus.

I do understand the problem that this patch is trying to solve.


> > I am happy that this is getting cleaned up, I just don't like a half cleanup
> > where we, after this commit, will setup+teardown iATU entries that will then
> > never be used for the actual transaction.
> > 
> 
> This should be done as a follow-up, not blocking this patch.

Fine with me.


Kind regards,
Niklas