iommu/arm-smmu-qcom: Request direct mapping for modem device
Subsystems (2)
PATCH v6 1/1 iommu/arm-smmu-qcom: Request direct mapping for modem device
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.
---
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(+)
drivers/iommu/arm-smmu-qcom.c +2 -0
@@ -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" }, { } };
Signature · 7 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 7 lines · 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.
Quoted 5 lines
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.
Regards,
Bjorn
Quoted 27 lines
Signed-off-by Sibi Sankar <[email protected]>---
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(+)drivers/iommu/arm-smmu-qcom.c +2
-0@@ -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" }, { } };Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Quoting Sibi Sankar (2020-05-11 10:55:32)
Quoted 7 lines
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.
Quoted 7 lines
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 <[email protected]>---
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hey Will,
Quoted 7 lines · 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.
Quoted 7 lines
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 <[email protected]>---
Now that the patch is reworded can
you please pick it up since its the
only pending path from the series.
Quoted 22 lines
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(+)drivers/iommu/arm-smmu-qcom.c +2
-0@@ -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" }, { } };
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Quoted 8 lines · 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.
[...]
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,
Signature · 5 lines
Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev