linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device
@ 2020-05-11 17:55 Sibi Sankar
  2020-05-11 19:31 ` Bjorn Andersson
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Sibi Sankar @ 2020-05-11 17:55 UTC (permalink / raw)
  To: will, robin.murphy, joro, swboyd
  Cc: bjorn.andersson, linux-kernel, linux-arm-msm, iommu,
	linux-arm-kernel, dianders, evgreen, mka, Sibi Sankar

The modem remote processor has two access paths to DDR. One path is
directly connected to DDR and another path goes through an SMMU. The
SMMU path is configured to be a direct mapping because it's used by
various peripherals in the modem subsystem. Typically this direct
mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor
Execution Environment) before the kernel is entered.

In certain firmware configuration, especially when the kernel is already
in full control of the SMMU, defer programming the modem SIDs to the
kernel. Let's add compatibles here so that we can have the kernel
program the SIDs for the modem in these cases.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---

V6
 * Rebased on Will's for-joerg/arm-smmu/updates
 * Reword commit message and add more details [Stephen]

 drivers/iommu/arm-smmu-qcom.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 5bedf21587a56..cf01d0215a397 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -17,7 +17,9 @@ static const struct of_device_id qcom_smmu_client_of_match[] = {
 	{ .compatible = "qcom,mdp4" },
 	{ .compatible = "qcom,mdss" },
 	{ .compatible = "qcom,sc7180-mdss" },
+	{ .compatible = "qcom,sc7180-mss-pil" },
 	{ .compatible = "qcom,sdm845-mdss" },
+	{ .compatible = "qcom,sdm845-mss-pil" },
 	{ }
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

* Re: [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device
  2020-05-11 17:55 [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device Sibi Sankar
@ 2020-05-11 19:31 ` Bjorn Andersson
  2020-05-11 19:37 ` Stephen Boyd
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Bjorn Andersson @ 2020-05-11 19:31 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: will, robin.murphy, joro, swboyd, linux-kernel, linux-arm-msm,
	iommu, linux-arm-kernel, dianders, evgreen, mka

On Mon 11 May 10:55 PDT 2020, Sibi Sankar wrote:

> The modem remote processor has two access paths to DDR. One path is
> directly connected to DDR and another path goes through an SMMU. The
> SMMU path is configured to be a direct mapping because it's used by
> various peripherals in the modem subsystem. Typically this direct
> mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor
> Execution Environment) before the kernel is entered.
> 
> In certain firmware configuration, especially when the kernel is already
> in full control of the SMMU, defer programming the modem SIDs to the
> kernel. Let's add compatibles here so that we can have the kernel
> program the SIDs for the modem in these cases.
> 

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

Regards,
Bjorn

> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
> 
> V6
>  * Rebased on Will's for-joerg/arm-smmu/updates
>  * Reword commit message and add more details [Stephen]
> 
>  drivers/iommu/arm-smmu-qcom.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
> index 5bedf21587a56..cf01d0215a397 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -17,7 +17,9 @@ static const struct of_device_id qcom_smmu_client_of_match[] = {
>  	{ .compatible = "qcom,mdp4" },
>  	{ .compatible = "qcom,mdss" },
>  	{ .compatible = "qcom,sc7180-mdss" },
> +	{ .compatible = "qcom,sc7180-mss-pil" },
>  	{ .compatible = "qcom,sdm845-mdss" },
> +	{ .compatible = "qcom,sdm845-mss-pil" },
>  	{ }
>  };
>  
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

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

* Re: [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device
  2020-05-11 17:55 [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device Sibi Sankar
  2020-05-11 19:31 ` Bjorn Andersson
@ 2020-05-11 19:37 ` Stephen Boyd
  2020-05-15  8:18 ` Sibi Sankar
  2020-05-18 23:04 ` Will Deacon
  3 siblings, 0 replies; 5+ messages in thread
From: Stephen Boyd @ 2020-05-11 19:37 UTC (permalink / raw)
  To: Sibi Sankar, joro, robin.murphy, will
  Cc: bjorn.andersson, linux-kernel, linux-arm-msm, iommu,
	linux-arm-kernel, dianders, evgreen, mka, Sibi Sankar

Quoting Sibi Sankar (2020-05-11 10:55:32)
> The modem remote processor has two access paths to DDR. One path is
> directly connected to DDR and another path goes through an SMMU. The
> SMMU path is configured to be a direct mapping because it's used by
> various peripherals in the modem subsystem. Typically this direct
> mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor
> Execution Environment) before the kernel is entered.
> 
> In certain firmware configuration, especially when the kernel is already
> in full control of the SMMU, defer programming the modem SIDs to the
> kernel. Let's add compatibles here so that we can have the kernel
> program the SIDs for the modem in these cases.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---

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

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

* Re: [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device
  2020-05-11 17:55 [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device Sibi Sankar
  2020-05-11 19:31 ` Bjorn Andersson
  2020-05-11 19:37 ` Stephen Boyd
@ 2020-05-15  8:18 ` Sibi Sankar
  2020-05-18 23:04 ` Will Deacon
  3 siblings, 0 replies; 5+ messages in thread
From: Sibi Sankar @ 2020-05-15  8:18 UTC (permalink / raw)
  To: will, robin.murphy, joro
  Cc: bjorn.andersson, linux-kernel, linux-arm-msm, iommu,
	linux-arm-kernel, dianders, evgreen, mka, linux-kernel-owner,
	swboyd

Hey Will,

On 2020-05-11 23:25, Sibi Sankar wrote:
> The modem remote processor has two access paths to DDR. One path is
> directly connected to DDR and another path goes through an SMMU. The
> SMMU path is configured to be a direct mapping because it's used by
> various peripherals in the modem subsystem. Typically this direct
> mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor
> Execution Environment) before the kernel is entered.
> 
> In certain firmware configuration, especially when the kernel is 
> already
> in full control of the SMMU, defer programming the modem SIDs to the
> kernel. Let's add compatibles here so that we can have the kernel
> program the SIDs for the modem in these cases.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---

Now that the patch is reworded can
you please pick it up since its the
only pending path from the series.

> 
> V6
>  * Rebased on Will's for-joerg/arm-smmu/updates
>  * Reword commit message and add more details [Stephen]
> 
>  drivers/iommu/arm-smmu-qcom.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu-qcom.c 
> b/drivers/iommu/arm-smmu-qcom.c
> index 5bedf21587a56..cf01d0215a397 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -17,7 +17,9 @@ static const struct of_device_id
> qcom_smmu_client_of_match[] = {
>  	{ .compatible = "qcom,mdp4" },
>  	{ .compatible = "qcom,mdss" },
>  	{ .compatible = "qcom,sc7180-mdss" },
> +	{ .compatible = "qcom,sc7180-mss-pil" },
>  	{ .compatible = "qcom,sdm845-mdss" },
> +	{ .compatible = "qcom,sdm845-mss-pil" },
>  	{ }
>  };

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

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

* Re: [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device
  2020-05-11 17:55 [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device Sibi Sankar
                   ` (2 preceding siblings ...)
  2020-05-15  8:18 ` Sibi Sankar
@ 2020-05-18 23:04 ` Will Deacon
  3 siblings, 0 replies; 5+ messages in thread
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
  To: robin.murphy, swboyd, joro, Sibi Sankar
  Cc: catalin.marinas, Will Deacon, dianders, iommu, bjorn.andersson,
	mka, linux-arm-msm, linux-arm-kernel, evgreen, linux-kernel

On Mon, 11 May 2020 23:25:32 +0530, Sibi Sankar wrote:
> The modem remote processor has two access paths to DDR. One path is
> directly connected to DDR and another path goes through an SMMU. The
> SMMU path is configured to be a direct mapping because it's used by
> various peripherals in the modem subsystem. Typically this direct
> mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor
> Execution Environment) before the kernel is entered.
> 
> [...]

Applied to will (for-joerg/arm-smmu/updates), thanks!

[1/1] iommu/arm-smmu-qcom: Request direct mapping for modem device
      https://git.kernel.org/will/c/d100ff3843b7

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

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

end of thread, other threads:[~2020-05-18 23:04 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-11 17:55 [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device Sibi Sankar
2020-05-11 19:31 ` Bjorn Andersson
2020-05-11 19:37 ` Stephen Boyd
2020-05-15  8:18 ` Sibi Sankar
2020-05-18 23:04 ` Will Deacon

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).