linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping
@ 2020-01-22 11:48 Sai Prakash Ranjan
  2020-01-22 11:48 ` [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation Sai Prakash Ranjan
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-01-22 11:48 UTC (permalink / raw)
  To: Will Deacon, Robin Murphy, Joerg Roedel, Jordan Crouse, Rob Clark
  Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak,
	Tomasz Figa, Sai Prakash Ranjan

This series allows drm devices to set a default identity
mapping using iommu_request_dm_for_dev(). First patch is
a cleanup to support other SoCs to call into QCOM specific
implementation and preparation for second patch.
Second patch sets the default identity domain for drm devices.

Jordan Crouse (1):
  iommu/arm-smmu: Allow client devices to select direct mapping

Sai Prakash Ranjan (1):
  iommu: arm-smmu-impl: Convert to a generic reset implementation

 drivers/iommu/arm-smmu-impl.c |  8 +++--
 drivers/iommu/arm-smmu-qcom.c | 55 +++++++++++++++++++++++++++++++++--
 drivers/iommu/arm-smmu.c      |  3 ++
 drivers/iommu/arm-smmu.h      |  5 ++++
 4 files changed, 65 insertions(+), 6 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation
  2020-01-22 11:48 [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
@ 2020-01-22 11:48 ` Sai Prakash Ranjan
  2020-02-09  0:00   ` Bjorn Andersson
                     ` (2 more replies)
  2020-01-22 11:48 ` [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
  2020-02-04 17:42 ` [PATCH 0/2] " Sai Prakash Ranjan
  2 siblings, 3 replies; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-01-22 11:48 UTC (permalink / raw)
  To: Will Deacon, Robin Murphy, Joerg Roedel, Jordan Crouse, Rob Clark
  Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak,
	Tomasz Figa, Sai Prakash Ranjan

Currently the QCOM specific smmu reset implementation is very
specific to SDM845 SoC and has a wait-for-safe logic which
may not be required for other SoCs. So move the SDM845 specific
logic to its specific reset function. Also add SC7180 SMMU
compatible for calling into QCOM specific implementation.

Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
 drivers/iommu/arm-smmu-impl.c |  8 +++++---
 drivers/iommu/arm-smmu-qcom.c | 16 +++++++++++++---
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index 74d97a886e93..c75b9d957b70 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -150,6 +150,8 @@ static const struct arm_smmu_impl arm_mmu500_impl = {
 
 struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
 {
+	const struct device_node *np = smmu->dev->of_node;
+
 	/*
 	 * We will inevitably have to combine model-specific implementation
 	 * quirks with platform-specific integration quirks, but everything
@@ -166,11 +168,11 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
 		break;
 	}
 
-	if (of_property_read_bool(smmu->dev->of_node,
-				  "calxeda,smmu-secure-config-access"))
+	if (of_property_read_bool(np, "calxeda,smmu-secure-config-access"))
 		smmu->impl = &calxeda_impl;
 
-	if (of_device_is_compatible(smmu->dev->of_node, "qcom,sdm845-smmu-500"))
+	if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
+	    of_device_is_compatible(np, "qcom,sc7180-smmu-500"))
 		return qcom_smmu_impl_init(smmu);
 
 	return smmu;
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 24c071c1d8b0..64a4ab270ab7 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -15,8 +15,6 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
 {
 	int ret;
 
-	arm_mmu500_reset(smmu);
-
 	/*
 	 * To address performance degradation in non-real time clients,
 	 * such as USB and UFS, turn off wait-for-safe on sdm845 based boards,
@@ -30,8 +28,20 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
 	return ret;
 }
 
+static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
+{
+	const struct device_node *np = smmu->dev->of_node;
+
+	arm_mmu500_reset(smmu);
+
+	if (of_device_is_compatible(np, "qcom,sdm845-smmu-500"))
+		return qcom_sdm845_smmu500_reset(smmu);
+
+	return 0;
+}
+
 static const struct arm_smmu_impl qcom_smmu_impl = {
-	.reset = qcom_sdm845_smmu500_reset,
+	.reset = qcom_smmu500_reset,
 };
 
 struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-01-22 11:48 [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
  2020-01-22 11:48 ` [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation Sai Prakash Ranjan
@ 2020-01-22 11:48 ` Sai Prakash Ranjan
  2020-04-13 23:12   ` Evan Green
  2020-04-16 13:58   ` Robin Murphy
  2020-02-04 17:42 ` [PATCH 0/2] " Sai Prakash Ranjan
  2 siblings, 2 replies; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-01-22 11:48 UTC (permalink / raw)
  To: Will Deacon, Robin Murphy, Joerg Roedel, Jordan Crouse, Rob Clark
  Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak,
	Tomasz Figa, Sai Prakash Ranjan

From: Jordan Crouse <jcrouse@codeaurora.org>

Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
 drivers/iommu/arm-smmu-qcom.c | 39 +++++++++++++++++++++++++++++++++++
 drivers/iommu/arm-smmu.c      |  3 +++
 drivers/iommu/arm-smmu.h      |  5 +++++
 3 files changed, 47 insertions(+)

diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 64a4ab270ab7..ff746acd1c81 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2019, The Linux Foundation. All rights reserved.
  */
 
+#include <linux/of_device.h>
 #include <linux/qcom_scm.h>
 
 #include "arm-smmu.h"
@@ -11,6 +12,43 @@ struct qcom_smmu {
 	struct arm_smmu_device smmu;
 };
 
+static const struct arm_smmu_client_match_data qcom_adreno = {
+	.direct_mapping = true,
+};
+
+static const struct arm_smmu_client_match_data qcom_mdss = {
+	.direct_mapping = true,
+};
+
+static const struct of_device_id qcom_smmu_client_of_match[] = {
+	{ .compatible = "qcom,adreno", .data = &qcom_adreno },
+	{ .compatible = "qcom,mdp4", .data = &qcom_mdss },
+	{ .compatible = "qcom,mdss", .data = &qcom_mdss },
+	{ .compatible = "qcom,sc7180-mdss", .data = &qcom_mdss },
+	{ .compatible = "qcom,sdm845-mdss", .data = &qcom_mdss },
+	{},
+};
+
+static const struct arm_smmu_client_match_data *
+qcom_smmu_client_data(struct device *dev)
+{
+	const struct of_device_id *match =
+		of_match_device(qcom_smmu_client_of_match, dev);
+
+	return match ? match->data : NULL;
+}
+
+static int qcom_smmu_request_domain(struct device *dev)
+{
+	const struct arm_smmu_client_match_data *client;
+
+	client = qcom_smmu_client_data(dev);
+	if (client)
+		iommu_request_dm_for_dev(dev);
+
+	return 0;
+}
+
 static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
 {
 	int ret;
@@ -41,6 +79,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
 }
 
 static const struct arm_smmu_impl qcom_smmu_impl = {
+	.req_domain = qcom_smmu_request_domain,
 	.reset = qcom_smmu500_reset,
 };
 
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 16c4b87af42b..67dd9326247a 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1448,6 +1448,9 @@ static int arm_smmu_add_device(struct device *dev)
 	device_link_add(dev, smmu->dev,
 			DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER);
 
+	if (smmu->impl && smmu->impl->req_domain)
+		return smmu->impl->req_domain(dev);
+
 	return 0;
 
 out_cfg_free:
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index 8d1cd54d82a6..059dc9c39f64 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -244,6 +244,10 @@ enum arm_smmu_arch_version {
 	ARM_SMMU_V2,
 };
 
+struct arm_smmu_client_match_data {
+	bool direct_mapping;
+};
+
 enum arm_smmu_implementation {
 	GENERIC_SMMU,
 	ARM_MMU500,
@@ -386,6 +390,7 @@ struct arm_smmu_impl {
 	int (*init_context)(struct arm_smmu_domain *smmu_domain);
 	void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
 			 int status);
+	int (*req_domain)(struct device *dev);
 };
 
 static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-01-22 11:48 [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
  2020-01-22 11:48 ` [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation Sai Prakash Ranjan
  2020-01-22 11:48 ` [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
@ 2020-02-04 17:42 ` Sai Prakash Ranjan
  2020-04-09 23:31   ` Matthias Kaehlcke
  2 siblings, 1 reply; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-02-04 17:42 UTC (permalink / raw)
  To: Will Deacon, Robin Murphy, Joerg Roedel, Jordan Crouse, Rob Clark
  Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak,
	Tomasz Figa

Hello Robin, Will

On 2020-01-22 17:18, Sai Prakash Ranjan wrote:
> This series allows drm devices to set a default identity
> mapping using iommu_request_dm_for_dev(). First patch is
> a cleanup to support other SoCs to call into QCOM specific
> implementation and preparation for second patch.
> Second patch sets the default identity domain for drm devices.
> 
> Jordan Crouse (1):
>   iommu/arm-smmu: Allow client devices to select direct mapping
> 
> Sai Prakash Ranjan (1):
>   iommu: arm-smmu-impl: Convert to a generic reset implementation
> 
>  drivers/iommu/arm-smmu-impl.c |  8 +++--
>  drivers/iommu/arm-smmu-qcom.c | 55 +++++++++++++++++++++++++++++++++--
>  drivers/iommu/arm-smmu.c      |  3 ++
>  drivers/iommu/arm-smmu.h      |  5 ++++
>  4 files changed, 65 insertions(+), 6 deletions(-)

Any review comments?

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation
  2020-01-22 11:48 ` [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation Sai Prakash Ranjan
@ 2020-02-09  0:00   ` Bjorn Andersson
  2020-02-14  2:44   ` Stephen Boyd
  2020-04-16 13:33   ` Robin Murphy
  2 siblings, 0 replies; 17+ messages in thread
From: Bjorn Andersson @ 2020-02-09  0:00 UTC (permalink / raw)
  To: Sai Prakash Ranjan
  Cc: Will Deacon, Robin Murphy, Joerg Roedel, Jordan Crouse,
	Rob Clark, iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Rajendra Nayak, Tomasz Figa

On Wed 22 Jan 03:48 PST 2020, Sai Prakash Ranjan wrote:

> Currently the QCOM specific smmu reset implementation is very
> specific to SDM845 SoC and has a wait-for-safe logic which
> may not be required for other SoCs. So move the SDM845 specific
> logic to its specific reset function. Also add SC7180 SMMU
> compatible for calling into QCOM specific implementation.
> 
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> ---
>  drivers/iommu/arm-smmu-impl.c |  8 +++++---
>  drivers/iommu/arm-smmu-qcom.c | 16 +++++++++++++---
>  2 files changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
> index 74d97a886e93..c75b9d957b70 100644
> --- a/drivers/iommu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm-smmu-impl.c
> @@ -150,6 +150,8 @@ static const struct arm_smmu_impl arm_mmu500_impl = {
>  
>  struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
>  {
> +	const struct device_node *np = smmu->dev->of_node;
> +
>  	/*
>  	 * We will inevitably have to combine model-specific implementation
>  	 * quirks with platform-specific integration quirks, but everything
> @@ -166,11 +168,11 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
>  		break;
>  	}
>  
> -	if (of_property_read_bool(smmu->dev->of_node,
> -				  "calxeda,smmu-secure-config-access"))
> +	if (of_property_read_bool(np, "calxeda,smmu-secure-config-access"))
>  		smmu->impl = &calxeda_impl;
>  
> -	if (of_device_is_compatible(smmu->dev->of_node, "qcom,sdm845-smmu-500"))
> +	if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
> +	    of_device_is_compatible(np, "qcom,sc7180-smmu-500"))
>  		return qcom_smmu_impl_init(smmu);
>  
>  	return smmu;
> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
> index 24c071c1d8b0..64a4ab270ab7 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -15,8 +15,6 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
>  {
>  	int ret;
>  
> -	arm_mmu500_reset(smmu);
> -
>  	/*
>  	 * To address performance degradation in non-real time clients,
>  	 * such as USB and UFS, turn off wait-for-safe on sdm845 based boards,
> @@ -30,8 +28,20 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
>  	return ret;
>  }
>  
> +static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
> +{
> +	const struct device_node *np = smmu->dev->of_node;
> +
> +	arm_mmu500_reset(smmu);
> +
> +	if (of_device_is_compatible(np, "qcom,sdm845-smmu-500"))
> +		return qcom_sdm845_smmu500_reset(smmu);
> +
> +	return 0;
> +}
> +
>  static const struct arm_smmu_impl qcom_smmu_impl = {
> -	.reset = qcom_sdm845_smmu500_reset,
> +	.reset = qcom_smmu500_reset,
>  };
>  
>  struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation
  2020-01-22 11:48 ` [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation Sai Prakash Ranjan
  2020-02-09  0:00   ` Bjorn Andersson
@ 2020-02-14  2:44   ` Stephen Boyd
  2020-04-16 13:33   ` Robin Murphy
  2 siblings, 0 replies; 17+ messages in thread
From: Stephen Boyd @ 2020-02-14  2:44 UTC (permalink / raw)
  To: Joerg Roedel, Jordan Crouse, Rob Clark, Robin Murphy,
	Sai Prakash Ranjan, Will Deacon
  Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak, Tomasz Figa,
	Sai Prakash Ranjan

Quoting Sai Prakash Ranjan (2020-01-22 03:48:01)
> Currently the QCOM specific smmu reset implementation is very
> specific to SDM845 SoC and has a wait-for-safe logic which
> may not be required for other SoCs. So move the SDM845 specific
> logic to its specific reset function. Also add SC7180 SMMU
> compatible for calling into QCOM specific implementation.
> 
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-02-04 17:42 ` [PATCH 0/2] " Sai Prakash Ranjan
@ 2020-04-09 23:31   ` Matthias Kaehlcke
  2020-04-11  9:20     ` Sai Prakash Ranjan
  2020-04-13 15:12     ` Jordan Crouse
  0 siblings, 2 replies; 17+ messages in thread
From: Matthias Kaehlcke @ 2020-04-09 23:31 UTC (permalink / raw)
  To: Sai Prakash Ranjan
  Cc: Will Deacon, Robin Murphy, Joerg Roedel, Jordan Crouse,
	Rob Clark, iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Bjorn Andersson, Rajendra Nayak, Tomasz Figa

On Tue, Feb 04, 2020 at 11:12:17PM +0530, Sai Prakash Ranjan wrote:
> Hello Robin, Will
> 
> On 2020-01-22 17:18, Sai Prakash Ranjan wrote:
> > This series allows drm devices to set a default identity
> > mapping using iommu_request_dm_for_dev(). First patch is
> > a cleanup to support other SoCs to call into QCOM specific
> > implementation and preparation for second patch.
> > Second patch sets the default identity domain for drm devices.
> > 
> > Jordan Crouse (1):
> >   iommu/arm-smmu: Allow client devices to select direct mapping
> > 
> > Sai Prakash Ranjan (1):
> >   iommu: arm-smmu-impl: Convert to a generic reset implementation
> > 
> >  drivers/iommu/arm-smmu-impl.c |  8 +++--
> >  drivers/iommu/arm-smmu-qcom.c | 55 +++++++++++++++++++++++++++++++++--
> >  drivers/iommu/arm-smmu.c      |  3 ++
> >  drivers/iommu/arm-smmu.h      |  5 ++++
> >  4 files changed, 65 insertions(+), 6 deletions(-)
> 
> Any review comments?

Ping

What is the status of this series, is it ready to land or are any changes
needed?

Thanks

Matthias

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-04-09 23:31   ` Matthias Kaehlcke
@ 2020-04-11  9:20     ` Sai Prakash Ranjan
  2020-04-13 15:12     ` Jordan Crouse
  1 sibling, 0 replies; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-04-11  9:20 UTC (permalink / raw)
  To: Matthias Kaehlcke, Will Deacon, Robin Murphy
  Cc: Joerg Roedel, Jordan Crouse, Rob Clark, iommu, linux-arm-kernel,
	linux-kernel, linux-arm-msm, Stephen Boyd, Bjorn Andersson,
	Rajendra Nayak, Tomasz Figa

Hi Matthias,

On 2020-04-10 05:01, Matthias Kaehlcke wrote:
> On Tue, Feb 04, 2020 at 11:12:17PM +0530, Sai Prakash Ranjan wrote:
>> Hello Robin, Will
>> 
>> On 2020-01-22 17:18, Sai Prakash Ranjan wrote:
>> > This series allows drm devices to set a default identity
>> > mapping using iommu_request_dm_for_dev(). First patch is
>> > a cleanup to support other SoCs to call into QCOM specific
>> > implementation and preparation for second patch.
>> > Second patch sets the default identity domain for drm devices.
>> >
>> > Jordan Crouse (1):
>> >   iommu/arm-smmu: Allow client devices to select direct mapping
>> >
>> > Sai Prakash Ranjan (1):
>> >   iommu: arm-smmu-impl: Convert to a generic reset implementation
>> >
>> >  drivers/iommu/arm-smmu-impl.c |  8 +++--
>> >  drivers/iommu/arm-smmu-qcom.c | 55 +++++++++++++++++++++++++++++++++--
>> >  drivers/iommu/arm-smmu.c      |  3 ++
>> >  drivers/iommu/arm-smmu.h      |  5 ++++
>> >  4 files changed, 65 insertions(+), 6 deletions(-)
>> 
>> Any review comments?
> 
> Ping
> 
> What is the status of this series, is it ready to land or are any 
> changes
> needed?
> 

I am wondering the same :)

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-04-09 23:31   ` Matthias Kaehlcke
  2020-04-11  9:20     ` Sai Prakash Ranjan
@ 2020-04-13 15:12     ` Jordan Crouse
  1 sibling, 0 replies; 17+ messages in thread
From: Jordan Crouse @ 2020-04-13 15:12 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Sai Prakash Ranjan, Will Deacon, Robin Murphy, Joerg Roedel,
	Rob Clark, iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Bjorn Andersson, Rajendra Nayak, Tomasz Figa

On Thu, Apr 09, 2020 at 04:31:24PM -0700, Matthias Kaehlcke wrote:
> On Tue, Feb 04, 2020 at 11:12:17PM +0530, Sai Prakash Ranjan wrote:
> > Hello Robin, Will
> > 
> > On 2020-01-22 17:18, Sai Prakash Ranjan wrote:
> > > This series allows drm devices to set a default identity
> > > mapping using iommu_request_dm_for_dev(). First patch is
> > > a cleanup to support other SoCs to call into QCOM specific
> > > implementation and preparation for second patch.
> > > Second patch sets the default identity domain for drm devices.
> > > 
> > > Jordan Crouse (1):
> > >   iommu/arm-smmu: Allow client devices to select direct mapping
> > > 
> > > Sai Prakash Ranjan (1):
> > >   iommu: arm-smmu-impl: Convert to a generic reset implementation
> > > 
> > >  drivers/iommu/arm-smmu-impl.c |  8 +++--
> > >  drivers/iommu/arm-smmu-qcom.c | 55 +++++++++++++++++++++++++++++++++--
> > >  drivers/iommu/arm-smmu.c      |  3 ++
> > >  drivers/iommu/arm-smmu.h      |  5 ++++
> > >  4 files changed, 65 insertions(+), 6 deletions(-)
> > 
> > Any review comments?
> 
> Ping
> 
> What is the status of this series, is it ready to land or are any changes
> needed?
> 
> Thanks
> 
> Matthias

I think this is up in the air following the changes that Joerg suggested:
https://lists.linuxfoundation.org/pipermail/iommu/2020-April/043017.html

Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-01-22 11:48 ` [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
@ 2020-04-13 23:12   ` Evan Green
  2020-04-14 16:18     ` Sai Prakash Ranjan
  2020-04-16 13:58   ` Robin Murphy
  1 sibling, 1 reply; 17+ messages in thread
From: Evan Green @ 2020-04-13 23:12 UTC (permalink / raw)
  To: Sai Prakash Ranjan
  Cc: Will Deacon, Robin Murphy, Joerg Roedel, Jordan Crouse,
	Rob Clark, iommu, linux-arm Mailing List, LKML, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak,
	Tomasz Figa

On Wed, Jan 22, 2020 at 3:48 AM Sai Prakash Ranjan
<saiprakash.ranjan@codeaurora.org> wrote:
>
> From: Jordan Crouse <jcrouse@codeaurora.org>
>
> Some client devices want to directly map the IOMMU themselves instead
> of using the DMA domain. Allow those devices to opt in to direct
> mapping by way of a list of compatible strings.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---
>  drivers/iommu/arm-smmu-qcom.c | 39 +++++++++++++++++++++++++++++++++++
>  drivers/iommu/arm-smmu.c      |  3 +++
>  drivers/iommu/arm-smmu.h      |  5 +++++
>  3 files changed, 47 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
> index 64a4ab270ab7..ff746acd1c81 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -3,6 +3,7 @@
>   * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>   */
>
> +#include <linux/of_device.h>
>  #include <linux/qcom_scm.h>
>
>  #include "arm-smmu.h"
> @@ -11,6 +12,43 @@ struct qcom_smmu {
>         struct arm_smmu_device smmu;
>  };
>
> +static const struct arm_smmu_client_match_data qcom_adreno = {
> +       .direct_mapping = true,
> +};
> +
> +static const struct arm_smmu_client_match_data qcom_mdss = {
> +       .direct_mapping = true,

I don't actually see direct_mapping being used. Shouldn't this member
be checked somewhere?

-Evan

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-04-13 23:12   ` Evan Green
@ 2020-04-14 16:18     ` Sai Prakash Ranjan
  0 siblings, 0 replies; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-04-14 16:18 UTC (permalink / raw)
  To: Evan Green
  Cc: Will Deacon, Robin Murphy, Joerg Roedel, Jordan Crouse,
	Rob Clark, iommu, linux-arm Mailing List, LKML, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak,
	Tomasz Figa

Hi Evan,

On 2020-04-14 04:42, Evan Green wrote:
> On Wed, Jan 22, 2020 at 3:48 AM Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>> 
>> From: Jordan Crouse <jcrouse@codeaurora.org>
>> 
>> Some client devices want to directly map the IOMMU themselves instead
>> of using the DMA domain. Allow those devices to opt in to direct
>> mapping by way of a list of compatible strings.
>> 
>> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
>> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> ---
>>  drivers/iommu/arm-smmu-qcom.c | 39 
>> +++++++++++++++++++++++++++++++++++
>>  drivers/iommu/arm-smmu.c      |  3 +++
>>  drivers/iommu/arm-smmu.h      |  5 +++++
>>  3 files changed, 47 insertions(+)
>> 
>> diff --git a/drivers/iommu/arm-smmu-qcom.c 
>> b/drivers/iommu/arm-smmu-qcom.c
>> index 64a4ab270ab7..ff746acd1c81 100644
>> --- a/drivers/iommu/arm-smmu-qcom.c
>> +++ b/drivers/iommu/arm-smmu-qcom.c
>> @@ -3,6 +3,7 @@
>>   * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>>   */
>> 
>> +#include <linux/of_device.h>
>>  #include <linux/qcom_scm.h>
>> 
>>  #include "arm-smmu.h"
>> @@ -11,6 +12,43 @@ struct qcom_smmu {
>>         struct arm_smmu_device smmu;
>>  };
>> 
>> +static const struct arm_smmu_client_match_data qcom_adreno = {
>> +       .direct_mapping = true,
>> +};
>> +
>> +static const struct arm_smmu_client_match_data qcom_mdss = {
>> +       .direct_mapping = true,
> 
> I don't actually see direct_mapping being used. Shouldn't this member
> be checked somewhere?
> 

Thanks for spotting this, my bad. It should be checked in 
qcom_smmu_request_domain().

diff --git a/drivers/iommu/arm-smmu-qcom.c 
b/drivers/iommu/arm-smmu-qcom.c
index ff746acd1c81..3ff62ca13ad5 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -43,7 +43,7 @@ static int qcom_smmu_request_domain(struct device 
*dev)
         const struct arm_smmu_client_match_data *client;

         client = qcom_smmu_client_data(dev);
-       if (client)
+       if (client && client->direct_mapping)
                 iommu_request_dm_for_dev(dev);

         return 0;

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation
  2020-01-22 11:48 ` [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation Sai Prakash Ranjan
  2020-02-09  0:00   ` Bjorn Andersson
  2020-02-14  2:44   ` Stephen Boyd
@ 2020-04-16 13:33   ` Robin Murphy
  2 siblings, 0 replies; 17+ messages in thread
From: Robin Murphy @ 2020-04-16 13:33 UTC (permalink / raw)
  To: Sai Prakash Ranjan, Will Deacon, Joerg Roedel, Jordan Crouse, Rob Clark
  Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak,
	Tomasz Figa

On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
> Currently the QCOM specific smmu reset implementation is very
> specific to SDM845 SoC and has a wait-for-safe logic which
> may not be required for other SoCs. So move the SDM845 specific
> logic to its specific reset function. Also add SC7180 SMMU
> compatible for calling into QCOM specific implementation.
> 
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---
>   drivers/iommu/arm-smmu-impl.c |  8 +++++---
>   drivers/iommu/arm-smmu-qcom.c | 16 +++++++++++++---
>   2 files changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
> index 74d97a886e93..c75b9d957b70 100644
> --- a/drivers/iommu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm-smmu-impl.c
> @@ -150,6 +150,8 @@ static const struct arm_smmu_impl arm_mmu500_impl = {
>   
>   struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
>   {
> +	const struct device_node *np = smmu->dev->of_node;
> +
>   	/*
>   	 * We will inevitably have to combine model-specific implementation
>   	 * quirks with platform-specific integration quirks, but everything
> @@ -166,11 +168,11 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
>   		break;
>   	}
>   
> -	if (of_property_read_bool(smmu->dev->of_node,
> -				  "calxeda,smmu-secure-config-access"))
> +	if (of_property_read_bool(np, "calxeda,smmu-secure-config-access"))
>   		smmu->impl = &calxeda_impl;
>   
> -	if (of_device_is_compatible(smmu->dev->of_node, "qcom,sdm845-smmu-500"))
> +	if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
> +	    of_device_is_compatible(np, "qcom,sc7180-smmu-500"))
>   		return qcom_smmu_impl_init(smmu);
>   
>   	return smmu;
> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
> index 24c071c1d8b0..64a4ab270ab7 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -15,8 +15,6 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
>   {
>   	int ret;
>   
> -	arm_mmu500_reset(smmu);
> -
>   	/*
>   	 * To address performance degradation in non-real time clients,
>   	 * such as USB and UFS, turn off wait-for-safe on sdm845 based boards,
> @@ -30,8 +28,20 @@ static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
>   	return ret;
>   }
>   
> +static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
> +{
> +	const struct device_node *np = smmu->dev->of_node;
> +
> +	arm_mmu500_reset(smmu);
> +
> +	if (of_device_is_compatible(np, "qcom,sdm845-smmu-500"))
> +		return qcom_sdm845_smmu500_reset(smmu);
> +
> +	return 0;
> +}
> +
>   static const struct arm_smmu_impl qcom_smmu_impl = {
> -	.reset = qcom_sdm845_smmu500_reset,
> +	.reset = qcom_smmu500_reset,
>   };

It might be logical to have a separate SDM845 impl rather than 
indirecting within the callback itself, but I'm not too concerned either 
way. For the arm-smmu-impl.c changes,

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

Thanks,
Robin.

>   
>   struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
> 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-01-22 11:48 ` [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
  2020-04-13 23:12   ` Evan Green
@ 2020-04-16 13:58   ` Robin Murphy
  2020-04-16 16:23     ` Sai Prakash Ranjan
  1 sibling, 1 reply; 17+ messages in thread
From: Robin Murphy @ 2020-04-16 13:58 UTC (permalink / raw)
  To: Sai Prakash Ranjan, Will Deacon, Joerg Roedel, Jordan Crouse, Rob Clark
  Cc: iommu, linux-arm-kernel, linux-kernel, linux-arm-msm,
	Stephen Boyd, Matthias Kaehlcke, Bjorn Andersson, Rajendra Nayak,
	Tomasz Figa

On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
> From: Jordan Crouse <jcrouse@codeaurora.org>
> 
> Some client devices want to directly map the IOMMU themselves instead
> of using the DMA domain. Allow those devices to opt in to direct
> mapping by way of a list of compatible strings.
> 
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---
>   drivers/iommu/arm-smmu-qcom.c | 39 +++++++++++++++++++++++++++++++++++
>   drivers/iommu/arm-smmu.c      |  3 +++
>   drivers/iommu/arm-smmu.h      |  5 +++++
>   3 files changed, 47 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
> index 64a4ab270ab7..ff746acd1c81 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -3,6 +3,7 @@
>    * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>    */
>   
> +#include <linux/of_device.h>
>   #include <linux/qcom_scm.h>
>   
>   #include "arm-smmu.h"
> @@ -11,6 +12,43 @@ struct qcom_smmu {
>   	struct arm_smmu_device smmu;
>   };
>   
> +static const struct arm_smmu_client_match_data qcom_adreno = {
> +	.direct_mapping = true,
> +};
> +
> +static const struct arm_smmu_client_match_data qcom_mdss = {
> +	.direct_mapping = true,
> +};

Might it make sense to group these by the desired SMMU behaviour rather 
than (apparently) what kind of device the client happens to be, which 
seems like a completely arbitrary distinction from the SMMU driver's PoV?

> +
> +static const struct of_device_id qcom_smmu_client_of_match[] = {
> +	{ .compatible = "qcom,adreno", .data = &qcom_adreno },
> +	{ .compatible = "qcom,mdp4", .data = &qcom_mdss },
> +	{ .compatible = "qcom,mdss", .data = &qcom_mdss },
> +	{ .compatible = "qcom,sc7180-mdss", .data = &qcom_mdss },
> +	{ .compatible = "qcom,sdm845-mdss", .data = &qcom_mdss },
> +	{},
> +};
> +
> +static const struct arm_smmu_client_match_data *
> +qcom_smmu_client_data(struct device *dev)
> +{
> +	const struct of_device_id *match =
> +		of_match_device(qcom_smmu_client_of_match, dev);
> +
> +	return match ? match->data : NULL;

of_device_get_match_data() is your friend.

> +}
> +
> +static int qcom_smmu_request_domain(struct device *dev)
> +{
> +	const struct arm_smmu_client_match_data *client;
> +
> +	client = qcom_smmu_client_data(dev);
> +	if (client)
> +		iommu_request_dm_for_dev(dev);
> +
> +	return 0;
> +}
> +
>   static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
>   {
>   	int ret;
> @@ -41,6 +79,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
>   }
>   
>   static const struct arm_smmu_impl qcom_smmu_impl = {
> +	.req_domain = qcom_smmu_request_domain,
>   	.reset = qcom_smmu500_reset,
>   };
>   
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 16c4b87af42b..67dd9326247a 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1448,6 +1448,9 @@ static int arm_smmu_add_device(struct device *dev)
>   	device_link_add(dev, smmu->dev,
>   			DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER);
>   
> +	if (smmu->impl && smmu->impl->req_domain)
> +		return smmu->impl->req_domain(dev);
> +

There are about 5 different patchsets flying around at the moment that 
all touch default domain allocation, so this is a fast-moving target, 
but I think where the dust should settle is with arm_smmu_ops forwarding 
.def_domain_type (or whatever it ends up as) calls to arm_smmu_impl as 
appropriate.

>   	return 0;
>   
>   out_cfg_free:
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index 8d1cd54d82a6..059dc9c39f64 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -244,6 +244,10 @@ enum arm_smmu_arch_version {
>   	ARM_SMMU_V2,
>   };
>   
> +struct arm_smmu_client_match_data {
> +	bool direct_mapping;
> +};

Does this need to be public? I don't see the other users...

Robin.

> +
>   enum arm_smmu_implementation {
>   	GENERIC_SMMU,
>   	ARM_MMU500,
> @@ -386,6 +390,7 @@ struct arm_smmu_impl {
>   	int (*init_context)(struct arm_smmu_domain *smmu_domain);
>   	void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
>   			 int status);
> +	int (*req_domain)(struct device *dev);
>   };
>   
>   static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
> 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-04-16 13:58   ` Robin Murphy
@ 2020-04-16 16:23     ` Sai Prakash Ranjan
  2020-04-16 17:17       ` Robin Murphy
  0 siblings, 1 reply; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-04-16 16:23 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Will Deacon, Joerg Roedel, Jordan Crouse, Rob Clark, Tomasz Figa,
	Rajendra Nayak, linux-arm-msm, linux-kernel, Stephen Boyd, iommu,
	Matthias Kaehlcke, Bjorn Andersson, linux-arm-kernel

Hi Robin,

On 2020-04-16 19:28, Robin Murphy wrote:
> On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
>> From: Jordan Crouse <jcrouse@codeaurora.org>
>> 
>> Some client devices want to directly map the IOMMU themselves instead
>> of using the DMA domain. Allow those devices to opt in to direct
>> mapping by way of a list of compatible strings.
>> 
>> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
>> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> ---
>>   drivers/iommu/arm-smmu-qcom.c | 39 
>> +++++++++++++++++++++++++++++++++++
>>   drivers/iommu/arm-smmu.c      |  3 +++
>>   drivers/iommu/arm-smmu.h      |  5 +++++
>>   3 files changed, 47 insertions(+)
>> 
>> diff --git a/drivers/iommu/arm-smmu-qcom.c 
>> b/drivers/iommu/arm-smmu-qcom.c
>> index 64a4ab270ab7..ff746acd1c81 100644
>> --- a/drivers/iommu/arm-smmu-qcom.c
>> +++ b/drivers/iommu/arm-smmu-qcom.c
>> @@ -3,6 +3,7 @@
>>    * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>>    */
>>   +#include <linux/of_device.h>
>>   #include <linux/qcom_scm.h>
>>     #include "arm-smmu.h"
>> @@ -11,6 +12,43 @@ struct qcom_smmu {
>>   	struct arm_smmu_device smmu;
>>   };
>>   +static const struct arm_smmu_client_match_data qcom_adreno = {
>> +	.direct_mapping = true,
>> +};
>> +
>> +static const struct arm_smmu_client_match_data qcom_mdss = {
>> +	.direct_mapping = true,
>> +};
> 
> Might it make sense to group these by the desired SMMU behaviour
> rather than (apparently) what kind of device the client happens to be,
> which seems like a completely arbitrary distinction from the SMMU
> driver's PoV?
> 

Sorry, I did not get the "grouping by the desired SMMU behaviour" thing.
Could you please give some more details?

>> +
>> +static const struct of_device_id qcom_smmu_client_of_match[] = {
>> +	{ .compatible = "qcom,adreno", .data = &qcom_adreno },
>> +	{ .compatible = "qcom,mdp4", .data = &qcom_mdss },
>> +	{ .compatible = "qcom,mdss", .data = &qcom_mdss },
>> +	{ .compatible = "qcom,sc7180-mdss", .data = &qcom_mdss },
>> +	{ .compatible = "qcom,sdm845-mdss", .data = &qcom_mdss },
>> +	{},
>> +};
>> +
>> +static const struct arm_smmu_client_match_data *
>> +qcom_smmu_client_data(struct device *dev)
>> +{
>> +	const struct of_device_id *match =
>> +		of_match_device(qcom_smmu_client_of_match, dev);
>> +
>> +	return match ? match->data : NULL;
> 
> of_device_get_match_data() is your friend.
> 

Ok will use it.

>> +}
>> +
>> +static int qcom_smmu_request_domain(struct device *dev)
>> +{
>> +	const struct arm_smmu_client_match_data *client;
>> +
>> +	client = qcom_smmu_client_data(dev);
>> +	if (client)
>> +		iommu_request_dm_for_dev(dev);
>> +
>> +	return 0;
>> +}
>> +
>>   static int qcom_sdm845_smmu500_reset(struct arm_smmu_device *smmu)
>>   {
>>   	int ret;
>> @@ -41,6 +79,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device 
>> *smmu)
>>   }
>>     static const struct arm_smmu_impl qcom_smmu_impl = {
>> +	.req_domain = qcom_smmu_request_domain,
>>   	.reset = qcom_smmu500_reset,
>>   };
>>   diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 16c4b87af42b..67dd9326247a 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -1448,6 +1448,9 @@ static int arm_smmu_add_device(struct device 
>> *dev)
>>   	device_link_add(dev, smmu->dev,
>>   			DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER);
>>   +	if (smmu->impl && smmu->impl->req_domain)
>> +		return smmu->impl->req_domain(dev);
>> +
> 
> There are about 5 different patchsets flying around at the moment that
> all touch default domain allocation, so this is a fast-moving target,
> but I think where the dust should settle is with arm_smmu_ops
> forwarding .def_domain_type (or whatever it ends up as) calls to
> arm_smmu_impl as appropriate.
> 

I'll wait till the dust settles down and then post the next version.

>>   	return 0;
>>     out_cfg_free:
>> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
>> index 8d1cd54d82a6..059dc9c39f64 100644
>> --- a/drivers/iommu/arm-smmu.h
>> +++ b/drivers/iommu/arm-smmu.h
>> @@ -244,6 +244,10 @@ enum arm_smmu_arch_version {
>>   	ARM_SMMU_V2,
>>   };
>>   +struct arm_smmu_client_match_data {
>> +	bool direct_mapping;
>> +};
> 
> Does this need to be public? I don't see the other users...
> 

Will move this out.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-04-16 16:23     ` Sai Prakash Ranjan
@ 2020-04-16 17:17       ` Robin Murphy
  2020-04-16 17:43         ` Sai Prakash Ranjan
  0 siblings, 1 reply; 17+ messages in thread
From: Robin Murphy @ 2020-04-16 17:17 UTC (permalink / raw)
  To: Sai Prakash Ranjan
  Cc: Will Deacon, Joerg Roedel, Jordan Crouse, Rob Clark, Tomasz Figa,
	Rajendra Nayak, linux-arm-msm, linux-kernel, Stephen Boyd, iommu,
	Matthias Kaehlcke, Bjorn Andersson, linux-arm-kernel

On 2020-04-16 5:23 pm, Sai Prakash Ranjan wrote:
> Hi Robin,
> 
> On 2020-04-16 19:28, Robin Murphy wrote:
>> On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
>>> From: Jordan Crouse <jcrouse@codeaurora.org>
>>>
>>> Some client devices want to directly map the IOMMU themselves instead
>>> of using the DMA domain. Allow those devices to opt in to direct
>>> mapping by way of a list of compatible strings.
>>>
>>> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
>>> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>>> ---
>>>   drivers/iommu/arm-smmu-qcom.c | 39 +++++++++++++++++++++++++++++++++++
>>>   drivers/iommu/arm-smmu.c      |  3 +++
>>>   drivers/iommu/arm-smmu.h      |  5 +++++
>>>   3 files changed, 47 insertions(+)
>>>
>>> diff --git a/drivers/iommu/arm-smmu-qcom.c 
>>> b/drivers/iommu/arm-smmu-qcom.c
>>> index 64a4ab270ab7..ff746acd1c81 100644
>>> --- a/drivers/iommu/arm-smmu-qcom.c
>>> +++ b/drivers/iommu/arm-smmu-qcom.c
>>> @@ -3,6 +3,7 @@
>>>    * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>>>    */
>>>   +#include <linux/of_device.h>
>>>   #include <linux/qcom_scm.h>
>>>     #include "arm-smmu.h"
>>> @@ -11,6 +12,43 @@ struct qcom_smmu {
>>>       struct arm_smmu_device smmu;
>>>   };
>>>   +static const struct arm_smmu_client_match_data qcom_adreno = {
>>> +    .direct_mapping = true,
>>> +};
>>> +
>>> +static const struct arm_smmu_client_match_data qcom_mdss = {
>>> +    .direct_mapping = true,
>>> +};
>>
>> Might it make sense to group these by the desired SMMU behaviour
>> rather than (apparently) what kind of device the client happens to be,
>> which seems like a completely arbitrary distinction from the SMMU
>> driver's PoV?
>>
> 
> Sorry, I did not get the "grouping by the desired SMMU behaviour" thing.
> Could you please give some more details?

I mean this pattern:

device_a_data {
	.thing = this;
}

device_b_data {
	.thing = this;
}

device_c_data {
	.thing = that;
}

match[] = {
	{ .compatible = "A", .data = &device_a_data },
	{ .compatible = "B", .data = &device_b_data },
	{ .compatible = "C", .data = &device_c_data },
};

...vs. this pattern:

do_this {
	.thing = this;
}

do_that {
	.thing = that;
}

match[] = {
	{ .compatible = "A", .data = &do_this },
	{ .compatible = "B", .data = &do_this },
	{ .compatible = "C", .data = &do_that },
};

 From the perspective of the thing doing the thing, grouping the data by 
device is meaningless if all that matters is whether to do this or that. 
The second pattern expresses that more naturally.

Of course if every device turns out to need a unique combination of 
several behaviours, then there ends up being no practical difference 
except that it's probably easier to come up with nice names under the 
first pattern. I guess it's up to how you see this developing in future; 
whether you're likely to need fine-grained per-device control, or don't 
expect it to go much beyond domain type.

Robin.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping
  2020-04-16 17:17       ` Robin Murphy
@ 2020-04-16 17:43         ` Sai Prakash Ranjan
  0 siblings, 0 replies; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-04-16 17:43 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Will Deacon, Joerg Roedel, Jordan Crouse, Rob Clark, Tomasz Figa,
	Rajendra Nayak, linux-arm-msm, linux-kernel, Stephen Boyd, iommu,
	Matthias Kaehlcke, Bjorn Andersson, linux-arm-kernel

Hi Robin,

On 2020-04-16 22:47, Robin Murphy wrote:
> On 2020-04-16 5:23 pm, Sai Prakash Ranjan wrote:
>> Hi Robin,
>> 
>> On 2020-04-16 19:28, Robin Murphy wrote:
>>> On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
>>>> From: Jordan Crouse <jcrouse@codeaurora.org>
>>>> 
>>>> Some client devices want to directly map the IOMMU themselves 
>>>> instead
>>>> of using the DMA domain. Allow those devices to opt in to direct
>>>> mapping by way of a list of compatible strings.
>>>> 
>>>> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
>>>> Co-developed-by: Sai Prakash Ranjan 
>>>> <saiprakash.ranjan@codeaurora.org>
>>>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>>>> ---
>>>>   drivers/iommu/arm-smmu-qcom.c | 39 
>>>> +++++++++++++++++++++++++++++++++++
>>>>   drivers/iommu/arm-smmu.c      |  3 +++
>>>>   drivers/iommu/arm-smmu.h      |  5 +++++
>>>>   3 files changed, 47 insertions(+)
>>>> 
>>>> diff --git a/drivers/iommu/arm-smmu-qcom.c 
>>>> b/drivers/iommu/arm-smmu-qcom.c
>>>> index 64a4ab270ab7..ff746acd1c81 100644
>>>> --- a/drivers/iommu/arm-smmu-qcom.c
>>>> +++ b/drivers/iommu/arm-smmu-qcom.c
>>>> @@ -3,6 +3,7 @@
>>>>    * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>>>>    */
>>>>   +#include <linux/of_device.h>
>>>>   #include <linux/qcom_scm.h>
>>>>     #include "arm-smmu.h"
>>>> @@ -11,6 +12,43 @@ struct qcom_smmu {
>>>>       struct arm_smmu_device smmu;
>>>>   };
>>>>   +static const struct arm_smmu_client_match_data qcom_adreno = {
>>>> +    .direct_mapping = true,
>>>> +};
>>>> +
>>>> +static const struct arm_smmu_client_match_data qcom_mdss = {
>>>> +    .direct_mapping = true,
>>>> +};
>>> 
>>> Might it make sense to group these by the desired SMMU behaviour
>>> rather than (apparently) what kind of device the client happens to 
>>> be,
>>> which seems like a completely arbitrary distinction from the SMMU
>>> driver's PoV?
>>> 
>> 
>> Sorry, I did not get the "grouping by the desired SMMU behaviour" 
>> thing.
>> Could you please give some more details?
> 
> I mean this pattern:
> 
> device_a_data {
> 	.thing = this;
> }
> 
> device_b_data {
> 	.thing = this;
> }
> 
> device_c_data {
> 	.thing = that;
> }
> 
> match[] = {
> 	{ .compatible = "A", .data = &device_a_data },
> 	{ .compatible = "B", .data = &device_b_data },
> 	{ .compatible = "C", .data = &device_c_data },
> };
> 
> ...vs. this pattern:
> 
> do_this {
> 	.thing = this;
> }
> 
> do_that {
> 	.thing = that;
> }
> 
> match[] = {
> 	{ .compatible = "A", .data = &do_this },
> 	{ .compatible = "B", .data = &do_this },
> 	{ .compatible = "C", .data = &do_that },
> };
> 
> From the perspective of the thing doing the thing, grouping the data
> by device is meaningless if all that matters is whether to do this or
> that. The second pattern expresses that more naturally.
> 
> Of course if every device turns out to need a unique combination of
> several behaviours, then there ends up being no practical difference
> except that it's probably easier to come up with nice names under the
> first pattern. I guess it's up to how you see this developing in
> future; whether you're likely to need fine-grained per-device control,
> or don't expect it to go much beyond domain type.
> 

Thanks for explaining *this thing* :)
I will update the patch to follow the 2nd pattern as it makes more sense
to do_this or do_that directly. I'm not expecting anything other than
domain type atleast for now but hey we can always add the functionality
if the need arises.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping
@ 2020-04-15 10:11 Sai Prakash Ranjan
  0 siblings, 0 replies; 17+ messages in thread
From: Sai Prakash Ranjan @ 2020-04-15 10:11 UTC (permalink / raw)
  To: Matthias Kaehlcke, Jordan Crouse, Joerg Roedel
  Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Clark, iommu,
	linux-arm-kernel, linux-kernel, linux-arm-msm, Stephen Boyd,
	Bjorn Andersson, Rajendra Nayak, Tomasz Figa

Hi Joerg,

On 2020-04-13 20:42, Jordan Crouse wrote:
> On Thu, Apr 09, 2020 at 04:31:24PM -0700, Matthias Kaehlcke wrote:
>> On Tue, Feb 04, 2020 at 11:12:17PM +0530, Sai Prakash Ranjan wrote:
>> > Hello Robin, Will
>> >
>> > On 2020-01-22 17:18, Sai Prakash Ranjan wrote:
>> > > This series allows drm devices to set a default identity
>> > > mapping using iommu_request_dm_for_dev(). First patch is
>> > > a cleanup to support other SoCs to call into QCOM specific
>> > > implementation and preparation for second patch.
>> > > Second patch sets the default identity domain for drm devices.
>> > >
>> > > Jordan Crouse (1):
>> > >   iommu/arm-smmu: Allow client devices to select direct mapping
>> > >
>> > > Sai Prakash Ranjan (1):
>> > >   iommu: arm-smmu-impl: Convert to a generic reset implementation
>> > >
>> > >  drivers/iommu/arm-smmu-impl.c |  8 +++--
>> > >  drivers/iommu/arm-smmu-qcom.c | 55 +++++++++++++++++++++++++++++++++--
>> > >  drivers/iommu/arm-smmu.c      |  3 ++
>> > >  drivers/iommu/arm-smmu.h      |  5 ++++
>> > >  4 files changed, 65 insertions(+), 6 deletions(-)
>> >
>> > Any review comments?
>> 
>> Ping
>> 
>> What is the status of this series, is it ready to land or are any 
>> changes
>> needed?
>> 
>> Thanks
>> 
>> Matthias
> 
> I think this is up in the air following the changes that Joerg 
> suggested:
> https://lists.linuxfoundation.org/pipermail/iommu/2020-April/043017.html
> 

1st patch for generic reset in this series is independent and can be 
merged.
But seems like requesting direct mapping fails with the joerg's patch 
series.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2020-04-16 17:44 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-22 11:48 [PATCH 0/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
2020-01-22 11:48 ` [PATCH 1/2] iommu: arm-smmu-impl: Convert to a generic reset implementation Sai Prakash Ranjan
2020-02-09  0:00   ` Bjorn Andersson
2020-02-14  2:44   ` Stephen Boyd
2020-04-16 13:33   ` Robin Murphy
2020-01-22 11:48 ` [PATCH 2/2] iommu/arm-smmu: Allow client devices to select direct mapping Sai Prakash Ranjan
2020-04-13 23:12   ` Evan Green
2020-04-14 16:18     ` Sai Prakash Ranjan
2020-04-16 13:58   ` Robin Murphy
2020-04-16 16:23     ` Sai Prakash Ranjan
2020-04-16 17:17       ` Robin Murphy
2020-04-16 17:43         ` Sai Prakash Ranjan
2020-02-04 17:42 ` [PATCH 0/2] " Sai Prakash Ranjan
2020-04-09 23:31   ` Matthias Kaehlcke
2020-04-11  9:20     ` Sai Prakash Ranjan
2020-04-13 15:12     ` Jordan Crouse
2020-04-15 10:11 Sai Prakash Ranjan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).