On Tue, Oct 22, 2024 at 10:38:58AM +0200, Niklas Cassel wrote: > On Tue, Oct 22, 2024 at 10:51:53AM +0900, Damien Le Moal wrote: > > On 10/22/24 07:19, Bjorn Helgaas wrote: > > > On Sat, Oct 12, 2024 at 08:32:40PM +0900, Damien Le Moal wrote: > > > > DMA transfers that can be done using dedicated DMA rx/tx channels associated > > with the endpoint controller do not need to use this API as the mapping to > > the host PCI address space is automatically handled by the DMA driver. > > I disagree with this part. It think that it depends on the DMA controller. > > Looking at the manual for e.g. the embedded DMA controller on the DWC > controller (eDMA): > "" > When you do not want the iATU to translate outbound requests that are generated by the > internal DMA module, then you must implement one of the following approaches: > - Ensure that the combination of DMA channel programming and iATU control register > programming, causes no translation of DMA traffic to be done in the iATU. > or > - Activate the DMA bypass mode to allow request TLPs which are initiated by the DMA > controller to pass through the iATU untranslated. You can activate DMA bypass mode by > setting the DMA Bypass field of the iATU Control 2 Register (IATU_REGION_C- > TRL_OFF_2_OUTBOUND_0). > "" > > However, we also know that, if there is no match in the iATU table: > "" > The default behavior of the ATU when there is no address match in the outbound direction or no > TLP attribute match in the inbound direction, is to pass the transaction through. > "" > > I.e. if there is a iATU mapping (which is what pci_epc_map_addr() sets up), > the eDMA will take that into account. If there is none, it will go through > untranslated. > > > So for the eDMA embedded on the DWC controller, we do not strictly need to > call pci_epc_map_addr(). (However, we probably want to do it anyway, as long > as we haven't enabled DMA bypass mode, just to make sure that there is no > other iATU mapping in the mapping table that will affect our transfer.) > I do not recommend that. EPF driver *should* know how to isolate the address spaces between DMA and iATU. Creating the iATU mapping for the DMA address is just defeating the purpose of using DMA. If any overlap mapping is present, then the EPF driver has a bug! > However, if you think about a generic DMA controller, e.g. an ARM primecell > pl330, I don't see how it that DMA controller will be able to perform > transfers correctly if there is not an iATU mapping for the region that it > is reading/writing to. > I don't think the generic DMA controller can be used to read/write to remote memory. It needs to be integrated with the PCIe IP so that it can issue PCIe transactions. > So the safest thing, that will work with any DMA controller is probably to > always call pci_epc_map_addr() before doing the transfer. > > > However, as I pointed out in: > https://lore.kernel.org/lkml/Zg5oeDzq5u3jmKIu@ryzen/ > > This behavior is still inconsistent between PCI EPF drivers: > E.g. for pci-epf-test.c: > When using dedicated DMA rx/tx channels (epf_test->dma_private == true), > and when FLAG_USE_DMA is set, it currently always calls pci_epc_map_addr() > before doing the transfer. > > However for pci-epf-mhi.c: > When using dedicated DMA rx/tx channels and when MHI_EPF_USE_DMA is set, > it currently does not call pci_epc_map_addr() before doing the transfer. > Because, there are not going to be any overlapping mappings. But I agree with the inconsistency between EPF drivers though... - Mani -- மணிவண்ணன் சதாசிவம்
