RFC arm64: IOMMU-backed DMA mapping
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 5 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 5 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
On 16/01/15 07:21, Yong Wu wrote:
[...]
Quoted 8 lines
Quoted 8 lines
Now that the server seems to be properly accessible again, I've made a branch with both series available here:
git://linux-arm.org/linux-rmiommu/dmaNote that in the current state it also depends on having the ARM SMMU driver selected in the config, due to an oversight on my part :(
Quoted 8 lines
Quoted 2 lines
Robin.
Dear Robin,
We have test this patch on our SOC(mt8173),which have our own iommu
HW(it is not ARM SMMU), the patch could work well.Tested-by Yong Wu <[email protected]>
Thanks!
Quoted 14 lines
And I have some questiones about the usage:
1) If we create a iommu domain by ?arch_setup_dma_ops", then we would like to call the standard iommu interface, like ?iommu_set_fault_handle?,
How can we get the "structiommu_domain*"? (the ?dev_domain? is static.)2) If a device A call ?arch_setup_dma_ops? to create a iommu domain, and a client device B would like to join this iommu domain,
so it call ?iommu_dma_attach_device?. then the device B want to alloc the iommu memory, it call ?dma_alloc_attrs? whose first parameter should be the ?struct device *?of device A. Is it designed like this in this patch?
Quoted 4 lines
(In arch/arm, ?dev->archdata.dma_ops = &iommu_dma_ops? is in?arm_iommu_attach_devce?;
In this patch, this sentence is in ?arch_setup_dma_ops?).
At this point there's not really any support for devices managing their own IOMMUs - initially I've only been focusing on the case where dma-mapping handles everything transparently, with legacy 32-bit peripherals in mind. There's already been quite a lot of discussion over the shortcomings of the current arch_setup_dma_ops model (most recently, [1]), but it just-about-works on Juno where we have a single device behind each IOMMU (with the exception of the USB OHCI which falls foul of the domain-per-device approach and falls over because it can't understand addresses from the EHCI). We really need to get IOMMU groups working in order to manage domains properly, which for one thing requires fixing the current situation of devices getting attached to a domain before they've even been added to the bus. I've started looking into that, but I suspect it's going to be long and complicated.
Quoted 9 lines
3) void
arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, struct iommu_ops *iommu, bool coherent)
In this function, the second and third parameter are the dma address
base and size, can they work currently?
(take a example, I set thedma_baseis 0, size is0x40000000while callingarch_setup_dma_ops,
then I alloc a range iova whose size is 50*SZ_4K, the return iova is0xfffce000, it is over0x40000000.)
That'll be coming from __alloc_iova using the device's dma_mask as an upper limit. Whilst I'm not sure if having fixed translations per dma-ranges makes sense with an IOMMU present, there does seem to be a valid case for having a size smaller than the driver's dma_mask - e.g. a device that just happens to have some upper address lines tied off in a particular implementation - so I'll change that to properly respect the dma-ranges values.
Robin.
[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/7556/focus=8237