On 2020-08-20 21:16, Dmitry Osipenko wrote:
20.08.2020 18:08, Robin Murphy пишет:
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy <robin.murphy@xxxxxxx>
---
drivers/iommu/tegra-gart.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index fac720273889..e081387080f6 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -9,6 +9,7 @@
#define dev_fmt(fmt) "gart: " fmt
+#include <linux/dma-iommu.h>
#include <linux/io.h>
#include <linux/iommu.h>
#include <linux/moduleparam.h>
@@ -145,16 +146,22 @@ static struct iommu_domain *gart_iommu_domain_alloc(unsigned type)
{
struct iommu_domain *domain;
Hello, Robin!
Tegra20 GART isn't a real IOMMU, but a small relocation aperture. We
would only want to use it for a temporal mappings (managed by GPU
driver) for the time while GPU hardware is busy and working with a
sparse DMA buffers, the driver will take care of unmapping the sparse
buffers once GPU work is finished [1]. In a case of contiguous DMA
buffers, we want to bypass the IOMMU and use buffer's phys address
because GART aperture is small and all buffers simply can't fit into
GART for a complex GPU operations that involve multiple buffers [2][3].
The upstream GPU driver still doesn't support GART, but eventually it
needs to be changed.
[1]
https://github.com/grate-driver/linux/blob/master/drivers/gpu/drm/tegra/gart.c#L489
[2]
https://github.com/grate-driver/linux/blob/master/drivers/gpu/drm/tegra/gart.c#L542
[3]
https://github.com/grate-driver/linux/blob/master/drivers/gpu/drm/tegra/uapi/patching.c#L90
- if (type != IOMMU_DOMAIN_UNMANAGED)
+ if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
return NULL;
Will a returned NULL tell to IOMMU core that implicit domain shouldn't
be used? Is it possible to leave this driver as-is?
The aim of this patch was just to make the conversion without functional
changes wherever possible, i.e. maintain an equivalent to the existing
ARM behaviour of allocating its own implicit domains for everything. It
doesn't represent any judgement of whether that was ever appropriate for
this driver in the first place ;)
Hopefully my other reply already covered the degree of control drivers
can have with proper default domains, but do shout if anything wasn't clear.
Cheers,
Robin.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
