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

[Manivannan Sadhasivam]

On 2026-09-13 19:16 +0200, Niklas Cassel wrote:
> On Sun, Sep 13, 2026 at 11:35:59AM +0200, Manivannan Sadhasivam wrote:
> > 
> > pci_epc_mem_map() is already useless in the eDMA path today. So this patch
> > doesn't change that.
> 
> I'm not sure if useless is the proper word here.
> Redundant is perhaps a better word.
> 

No, it is useless indeed. See below.

> 
> Let me explain using pci-epf-test.c:pci_epf_test_read() as an example:
> 
> 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.

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.

> So the iATU entry is actually being used.
> 
> 
> After the patch in $subject, on a DWC based platform:
> 
> pci_epc_mem_map() will setup an iATU entry, however, because of the DMA_BYPASS
> bit, that iATU entry will not be used, and the transaction will be send out on
> the PCIe bus untranslated.
> 

This is the current behaviour as well.

> 
> So I would argue that it is only after this patch that pci_epc_mem_map() will
> setup an iATU entry that will then never be used.
> 
> Yes, I think I understand that you are trying to say that, for DWC based
> drivers, we could theoretically skip the pci_epc_mem_map() call, and send the
> transaction untranslated.
> 
> My point is that it feels silly to set the DMA_BYPASS bit without also making
> sure that the pci_epc_mem_map() calls are either removed or (at least for DWC
> based platforms) modified to not set up an iATU entry in the DMA path in the
> first place.
> 

This I agree. But this also needs some careful analysis as other DMA controllers
other than eDMA might need the mapping. For eDMA, it is also not straightforward
as we do not pass any 'I'm using DMA' flag to map_addr() callback.

> 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.

- Mani