All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: thierry.reding@gmail.com
Cc: linux-tegra@vger.kernel.org, iommu@lists.linux-foundation.org,
	dmitry.osipenko@collabora.com, dri-devel@lists.freedesktop.org,
	jonathanh@nvidia.com
Subject: [PATCH v2] drm/tegra: Stop using iommu_present()
Date: Mon, 11 Apr 2022 14:46:43 +0100	[thread overview]
Message-ID: <1f7c304a79b8b8dd5d4716786cae7502a0cc31f5.1649684782.git.robin.murphy@arm.com> (raw)

Refactor the confusing logic to make it both clearer and more robust. If
the host1x parent device does have an IOMMU domain then iommu_present()
is redundantly true, while otherwise for the 32-bit DMA mask case it
still doesn't say whether the IOMMU driver actually knows about the DRM
device or not.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

v2: Fix logic for older SoCs and clarify.

 drivers/gpu/drm/tegra/drm.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 9464f522e257..4f2bdab31064 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct host1x_device *dev)
 	struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
 	struct iommu_domain *domain;
 
+	/* For starters, this is moot if no IOMMU is available */
+	if (!device_iommu_mapped(&dev->dev))
+		return false;
+
+	/*
+	 * Tegra20 and Tegra30 don't support addressing memory beyond the
+	 * 32-bit boundary, so the regular GATHER opcodes will always be
+	 * sufficient and whether or not the host1x is attached to an IOMMU
+	 * doesn't matter.
+	 */
+	if (host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32))
+		return true;
+
 	/*
 	 * If the Tegra DRM clients are backed by an IOMMU, push buffers are
 	 * likely to be allocated beyond the 32-bit boundary if sufficient
@@ -1122,14 +1135,13 @@ static bool host1x_drm_wants_iommu(struct host1x_device *dev)
 	domain = iommu_get_domain_for_dev(dev->dev.parent);
 
 	/*
-	 * Tegra20 and Tegra30 don't support addressing memory beyond the
-	 * 32-bit boundary, so the regular GATHER opcodes will always be
-	 * sufficient and whether or not the host1x is attached to an IOMMU
-	 * doesn't matter.
+	 * At the moment, the exact type of domain doesn't actually matter.
+	 * Only for 64-bit kernels might this be a managed DMA API domain, and
+	 * then only on newer SoCs using arm-smmu, since tegra-smmu doesn't
+	 * support default domains at all, and since those SoCs are the same
+	 * ones with extended GATHER support, even if it's a passthrough domain
+	 * it can still work out OK.
 	 */
-	if (!domain && host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32))
-		return true;
-
 	return domain != NULL;
 }
 
@@ -1149,7 +1161,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
 		goto put;
 	}
 
-	if (host1x_drm_wants_iommu(dev) && iommu_present(&platform_bus_type)) {
+	if (host1x_drm_wants_iommu(dev)) {
 		tegra->domain = iommu_domain_alloc(&platform_bus_type);
 		if (!tegra->domain) {
 			err = -ENOMEM;
-- 
2.28.0.dirty


WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: thierry.reding@gmail.com
Cc: jonathanh@nvidia.com, dri-devel@lists.freedesktop.org,
	linux-tegra@vger.kernel.org, iommu@lists.linux-foundation.org,
	dmitry.osipenko@collabora.com
Subject: [PATCH v2] drm/tegra: Stop using iommu_present()
Date: Mon, 11 Apr 2022 14:46:43 +0100	[thread overview]
Message-ID: <1f7c304a79b8b8dd5d4716786cae7502a0cc31f5.1649684782.git.robin.murphy@arm.com> (raw)

Refactor the confusing logic to make it both clearer and more robust. If
the host1x parent device does have an IOMMU domain then iommu_present()
is redundantly true, while otherwise for the 32-bit DMA mask case it
still doesn't say whether the IOMMU driver actually knows about the DRM
device or not.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

v2: Fix logic for older SoCs and clarify.

 drivers/gpu/drm/tegra/drm.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 9464f522e257..4f2bdab31064 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct host1x_device *dev)
 	struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
 	struct iommu_domain *domain;
 
+	/* For starters, this is moot if no IOMMU is available */
+	if (!device_iommu_mapped(&dev->dev))
+		return false;
+
+	/*
+	 * Tegra20 and Tegra30 don't support addressing memory beyond the
+	 * 32-bit boundary, so the regular GATHER opcodes will always be
+	 * sufficient and whether or not the host1x is attached to an IOMMU
+	 * doesn't matter.
+	 */
+	if (host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32))
+		return true;
+
 	/*
 	 * If the Tegra DRM clients are backed by an IOMMU, push buffers are
 	 * likely to be allocated beyond the 32-bit boundary if sufficient
@@ -1122,14 +1135,13 @@ static bool host1x_drm_wants_iommu(struct host1x_device *dev)
 	domain = iommu_get_domain_for_dev(dev->dev.parent);
 
 	/*
-	 * Tegra20 and Tegra30 don't support addressing memory beyond the
-	 * 32-bit boundary, so the regular GATHER opcodes will always be
-	 * sufficient and whether or not the host1x is attached to an IOMMU
-	 * doesn't matter.
+	 * At the moment, the exact type of domain doesn't actually matter.
+	 * Only for 64-bit kernels might this be a managed DMA API domain, and
+	 * then only on newer SoCs using arm-smmu, since tegra-smmu doesn't
+	 * support default domains at all, and since those SoCs are the same
+	 * ones with extended GATHER support, even if it's a passthrough domain
+	 * it can still work out OK.
 	 */
-	if (!domain && host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32))
-		return true;
-
 	return domain != NULL;
 }
 
@@ -1149,7 +1161,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
 		goto put;
 	}
 
-	if (host1x_drm_wants_iommu(dev) && iommu_present(&platform_bus_type)) {
+	if (host1x_drm_wants_iommu(dev)) {
 		tegra->domain = iommu_domain_alloc(&platform_bus_type);
 		if (!tegra->domain) {
 			err = -ENOMEM;
-- 
2.28.0.dirty


WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: thierry.reding@gmail.com
Cc: linux-tegra@vger.kernel.org, iommu@lists.linux-foundation.org,
	dmitry.osipenko@collabora.com, dri-devel@lists.freedesktop.org,
	jonathanh@nvidia.com
Subject: [PATCH v2] drm/tegra: Stop using iommu_present()
Date: Mon, 11 Apr 2022 14:46:43 +0100	[thread overview]
Message-ID: <1f7c304a79b8b8dd5d4716786cae7502a0cc31f5.1649684782.git.robin.murphy@arm.com> (raw)

Refactor the confusing logic to make it both clearer and more robust. If
the host1x parent device does have an IOMMU domain then iommu_present()
is redundantly true, while otherwise for the 32-bit DMA mask case it
still doesn't say whether the IOMMU driver actually knows about the DRM
device or not.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

v2: Fix logic for older SoCs and clarify.

 drivers/gpu/drm/tegra/drm.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 9464f522e257..4f2bdab31064 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct host1x_device *dev)
 	struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
 	struct iommu_domain *domain;
 
+	/* For starters, this is moot if no IOMMU is available */
+	if (!device_iommu_mapped(&dev->dev))
+		return false;
+
+	/*
+	 * Tegra20 and Tegra30 don't support addressing memory beyond the
+	 * 32-bit boundary, so the regular GATHER opcodes will always be
+	 * sufficient and whether or not the host1x is attached to an IOMMU
+	 * doesn't matter.
+	 */
+	if (host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32))
+		return true;
+
 	/*
 	 * If the Tegra DRM clients are backed by an IOMMU, push buffers are
 	 * likely to be allocated beyond the 32-bit boundary if sufficient
@@ -1122,14 +1135,13 @@ static bool host1x_drm_wants_iommu(struct host1x_device *dev)
 	domain = iommu_get_domain_for_dev(dev->dev.parent);
 
 	/*
-	 * Tegra20 and Tegra30 don't support addressing memory beyond the
-	 * 32-bit boundary, so the regular GATHER opcodes will always be
-	 * sufficient and whether or not the host1x is attached to an IOMMU
-	 * doesn't matter.
+	 * At the moment, the exact type of domain doesn't actually matter.
+	 * Only for 64-bit kernels might this be a managed DMA API domain, and
+	 * then only on newer SoCs using arm-smmu, since tegra-smmu doesn't
+	 * support default domains at all, and since those SoCs are the same
+	 * ones with extended GATHER support, even if it's a passthrough domain
+	 * it can still work out OK.
 	 */
-	if (!domain && host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32))
-		return true;
-
 	return domain != NULL;
 }
 
@@ -1149,7 +1161,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
 		goto put;
 	}
 
-	if (host1x_drm_wants_iommu(dev) && iommu_present(&platform_bus_type)) {
+	if (host1x_drm_wants_iommu(dev)) {
 		tegra->domain = iommu_domain_alloc(&platform_bus_type);
 		if (!tegra->domain) {
 			err = -ENOMEM;
-- 
2.28.0.dirty

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

             reply	other threads:[~2022-04-11 13:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11 13:46 Robin Murphy [this message]
2022-04-11 13:46 ` [PATCH v2] drm/tegra: Stop using iommu_present() Robin Murphy
2022-04-11 13:46 ` Robin Murphy
2022-04-13 22:34 ` Dmitry Osipenko
2022-04-13 22:34   ` Dmitry Osipenko
2022-04-13 22:34   ` Dmitry Osipenko
2022-05-04  0:52 ` Dmitry Osipenko
2022-05-04  0:52   ` Dmitry Osipenko
2022-05-04  0:52   ` Dmitry Osipenko
2022-05-04 11:52   ` Robin Murphy
2022-05-04 11:52     ` Robin Murphy
2022-05-04 11:52     ` Robin Murphy
2022-05-11 11:08     ` Dmitry Osipenko
2022-05-11 11:08       ` Dmitry Osipenko
2022-05-11 11:08       ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f7c304a79b8b8dd5d4716786cae7502a0cc31f5.1649684782.git.robin.murphy@arm.com \
    --to=robin.murphy@arm.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.