dmaengine: rcar-dmac: add iommu support for slave transfers
Get series with b4
b4 am 2277430.yNKNTgNkoj@wuerfelVersions newest first · linked by author and title
- v9 Latest posting 2/20 of 6 patches 0 repliesNew
- v9 posting 1/20 of 6 patches 0 repliesSuperseded
Patches in v9 posting 2/2 No applies recorded yet
None of the 6 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v9 yet.
Cover letter [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
Quoted 11 lines · CEST Laurent Pinchart
Quoted 8 lines
I wasn't thinking quite that far, though that is also a theoretical problem. However, the simple solution would be to have a bit in the DMA specifier let the driver know whether translation is needed or not.
The simpler case I was thinking of is where the entire DMA engine either goes through an IOMMU or doesn't (depending on the integration into the SoC), so we'd have to find out through some DT property or compatible string in the DMA enginen driver.
Don't we already get that information from the iommus DT property ? If the DMA engine goes through an IOMMU the property will be set, otherwise it will not.
It depends. A dmaengine typically at least has two DMA masters, possibly more. It's likely that some dmaengine implementations are connected to RAM through an IOMMU, but have direct access to an I/O bus for the slave FIFOs.
Quoted 10 lines
Quoted 4 lines
Quoted 2 lines
The problem is a bit broader than that, we'll also have an issue with DMA engines that have different channels served by different IOMMUs.
Do you mean a theoretical problem, or a chip that you already know exists?
That's theoretical. The problem I'm facing today is a DMA engine whose channels are served by different ports of the same IOMMU. This works in a suboptimal way because I have to keep all the IOMMU ports enabled regardless of whether they're used or not, as the DMA engine and IOMMU APIs don't carry channel information.
Ok
Arnd