Re: [PATCH v6] iommu/arm-smmu-qcom: Request direct mapping for modem device
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
---
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.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v6] 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.
Signed-off-by: Sibi Sankar
---
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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5] iommu/arm-smmu-qcom: Request direct mapping for modem device
Hey Stephen, Thanks for taking time to review the patch. On 5/8/20 2:44 AM, Stephen Boyd wrote: Quoting Sibi Sankar (2020-05-07 12:21:57) The modem remote processor has two modes of access to the DDR, a direct mode and through a SMMU which requires direct mapping. The configuration of the modem SIDs is handled in TrustZone. Is it "The configuration of the modem SIDs is typically handled by code running in the ARM CPU's secure mode, i.e. secure EL1"? And is that even true? I though it was programmed by EL2. What I meant to say was qcom implementation of TZ or qcom proprietary bootloaders. I should have been more specific and mentioned that the configuration is done at EL2 by QHEE (Qualcomm's Hypervisor Execution Environment) before we enter the kernel. On platforms where TrustZone TrustZone is always there. is absent this needs to be explicitly done from kernel. Add compatibles for modem to opt in for direct mapping on such platforms. Signed-off-by: Sai Prakash Ranjan Is Sai the author? Or does this need a co-developed-by tag? I decided to include Sai's S-b just to show I took back ownership of the patch from his patch series. I'll drop it in the next re-spin. Signed-off-by: Sibi Sankar --- V5 * Reword commit message and drop unnecessary details I don't see any improvement! Probably because I don't understand _why_ the modem needs a direct mapping. The commit text basically says "we need to do it because it isn't done in secure world sometimes". This is probably wrong what I wrote below, but I'd like to clarify to confirm my understanding. Maybe the commit text should say: Thanks for taking time to reword the commit message will use the same with a few corrections. 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. I'll use ^^ as is. Typically this direct mapping is configured by programming modem SIDs into the SMMU when EL2 responds to a hyp call from the code that loads the modem binary in the secure world. Typically this direct mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor Execution Environment) before the kernel is entered. In certain firmware configurations, especially when the kernel is entered at EL2, we don't want secure mode to make hyp calls to program the SMMU because the kernel is in full control of the SMMU. Let's add compatibles here so that we can have the kernel program the SIDs for the modem in these cases. 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. Will/Stephen, Let me know if the above changes are okay? I'll re-spin the patch based on your feedback. -- Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v5] iommu/arm-smmu-qcom: Request direct mapping for modem device
The modem remote processor has two modes of access to the DDR, a direct
mode and through a SMMU which requires direct mapping. The configuration
of the modem SIDs is handled in TrustZone. On platforms where TrustZone
is absent this needs to be explicitly done from kernel. Add compatibles
for modem to opt in for direct mapping on such platforms.
Signed-off-by: Sai Prakash Ranjan
Signed-off-by: Sibi Sankar
---
V5
* Reword commit message and drop unnecessary details
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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv4 4/6] iommu/arm-smmu-qcom: Request direct mapping for modem device
Hey WIll, On 2020-05-07 18:32, Will Deacon wrote: On Tue, Apr 21, 2020 at 12:03:52AM +0530, Sai Prakash Ranjan wrote: From: Sibi Sankar The Q6 modem sub-system has direct access to DDR through memnoc. Also SMMU is not expected to provide access control/translation for these SIDs (sandboxing of the modem is achieved through XPUs engaged using SMC calls). So request direct mapping for modem on platforms which don't have TrustZone. The Z7 space rocket framework has limited access to water through BROADCHAN. Also, this commit message really sucks. So please can you rewrite it in a way that makes sense to people outside of your office? lol, sure I'll re-word ^^ tday Will -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/3] Request direct mapping for modem device
On 2020-03-17 20:39, Sibi Sankar wrote: The Q6 modem sub-system has direct access to DDR through memnoc and an indirect access routed through a SMMU which MSS CE (crypto engine sub-component of MSS) uses during out of reset sequence. Request direct mapping for the modem device since smmu is not expected to provide access control/translation for these SIDs (sandboxing of the modem is achieved through XPUs engaged using SMC calls). This is done on platforms which don't have TrustZone (which programs the modem SIDs) to prevent the following global faults seen on Cheza/Trogdor: Cheza: arm-smmu 1500.iommu: Unexpected global fault, this could be serious arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x, GFSYNR1 0x0781, GFSYNR2 0x Trogdor: arm-smmu 1500.iommu: Unexpected global fault, this could be serious arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x, GFSYNR1 0x0461, GFSYNR2 0x V2: * Request direct mapping from SoC-specific corner of the SMMU driver [Robin] * Add iommu property to remoteproc modem node on Cheza Depends on: https://lore.kernel.org/patchwork/cover/1183528/ Sibi Sankar (3): dt-bindings: remoteproc: qcom: Add iommus property remoteproc: qcom_q6v5_mss: Request direct mapping for modem device iommu: arm-smmu-qcom: Request direct mapping for modem device sry should have been ^^ instead arm64: dts: qcom: sdm845-cheza: Add iommus property Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++ arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 4 drivers/iommu/arm-smmu-qcom.c | 6 ++ 3 files changed, 13 insertions(+) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/3] dt-bindings: remoteproc: qcom: Add iommus property
Add iommus property to allow Q6 modem to boot on platforms which do not have trustZone. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 88dfa3fc15f78..130e50aab7419 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -184,6 +184,9 @@ For the compatible strings below the following phandle references are required: followed by the offset within syscon for conn_box_spare0 register. +The Hexagon node must contain iommus property as described in ../iommu/iommu.txt +on platforms which do not have TrustZone. + = SUBNODES: The Hexagon node must contain two subnodes, named "mba" and "mpss" representing the memory regions used by the Hexagon firmware. Each sub-node must contain: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 3/3] arm64: dts: qcom: sdm845-cheza: Add iommus property
Add iommus property to remoteproc modem node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 8d16d016efec1..01c7d7cc95c2d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -626,6 +626,10 @@ &mdss_mdp {
status = "okay";
};
+&mss_pil {
+ iommus = <&apps_smmu 0x780 0x1>;
+};
+
&pm8998_pwrkey {
status = "disabled";
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 2/3] remoteproc: qcom_q6v5_mss: Request direct mapping for modem device
Request direct mapping for modem on platforms which don't have TrustZone
(which programs the modem SIDs) to prevent the following global faults seen
on Cheza/Trogdor:
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0781, GFSYNR2 0x
arm-smmu 1500.iommu: Unexpected global fault, this could be serious
arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x,
GFSYNR1 0x0461, GFSYNR2 0x
Signed-off-by: Sibi Sankar
---
drivers/iommu/arm-smmu-qcom.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index ff746acd1c816..5dd7a788f59e1 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -20,12 +20,18 @@ static const struct arm_smmu_client_match_data qcom_mdss = {
.direct_mapping = true,
};
+static const struct arm_smmu_client_match_data qcom_mss = {
+ .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,sc7180-mss-pil", .data = &qcom_mss },
{ .compatible = "qcom,sdm845-mdss", .data = &qcom_mdss },
+ { .compatible = "qcom,sdm845-mss-pil", .data = &qcom_mss },
{},
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/3] Request direct mapping for modem device
The Q6 modem sub-system has direct access to DDR through memnoc and an indirect access routed through a SMMU which MSS CE (crypto engine sub-component of MSS) uses during out of reset sequence. Request direct mapping for the modem device since smmu is not expected to provide access control/translation for these SIDs (sandboxing of the modem is achieved through XPUs engaged using SMC calls). This is done on platforms which don't have TrustZone (which programs the modem SIDs) to prevent the following global faults seen on Cheza/Trogdor: Cheza: arm-smmu 1500.iommu: Unexpected global fault, this could be serious arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x, GFSYNR1 0x0781, GFSYNR2 0x Trogdor: arm-smmu 1500.iommu: Unexpected global fault, this could be serious arm-smmu 1500.iommu: GFSR 0x8002, GFSYNR0 0x, GFSYNR1 0x0461, GFSYNR2 0x V2: * Request direct mapping from SoC-specific corner of the SMMU driver [Robin] * Add iommu property to remoteproc modem node on Cheza Depends on: https://lore.kernel.org/patchwork/cover/1183528/ Sibi Sankar (3): dt-bindings: remoteproc: qcom: Add iommus property remoteproc: qcom_q6v5_mss: Request direct mapping for modem device arm64: dts: qcom: sdm845-cheza: Add iommus property Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++ arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 4 drivers/iommu/arm-smmu-qcom.c | 6 ++ 3 files changed, 13 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/3] Request direct mapping for modem firmware subdevice
Hey Christoph,
Thanks for taking time to review
the series.
On 2020-03-16 21:20, Christoph Hellwig wrote:
On Mon, Mar 09, 2020 at 11:52:52PM +0530, Sibi Sankar wrote:
The Q6 modem sub-system has direct access to DDR through memnoc and
an indirect access routed through a SMMU which MSS CE (crypto engine
sub-component of MSS) uses during out of reset sequence. Request
direct
mapping for the modem-firmware subdevice since smmu is not expected
to provide access control/translation for these SIDs (sandboxing of
the
modem is achieved through XPUs engaged using SMC calls).
Please fix your device tree so that the device isn't bound to an
IOMMU.
the bindings proposed in the series
would add a sub-device with an iommu
property.
modem_pil: remoteproc@x {
...
modem-firmware {
iommus = <&apps_smmu 0x460 0x1>;
};
...
};
Remoteproc device will not have a iommu
property but modem-firmware sub-device
will.
With ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT y,
we would want to configure the SID either
in direct mapping or bypass (either will
do since protection is achieved through
other means)
https://lore.kernel.org/lkml/497e40b8-300f-1b83-4312-93a58c459...@arm.com/
Currently the restructuring is trending
towards whats discussed in the ^^ thread.
i.e either direct mapping/bypass will be
done in the SoC specific corner of the
SMMU driver.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/3] Request direct mapping for modem firmware subdevice
Hey Joerg, Thanks for taking time to review the series! On 2020-03-10 16:53, Joerg Roedel wrote: On Mon, Mar 09, 2020 at 11:52:52PM +0530, Sibi Sankar wrote: The Q6 modem sub-system has direct access to DDR through memnoc and an indirect access routed through a SMMU which MSS CE (crypto engine sub-component of MSS) uses during out of reset sequence. Request direct mapping for the modem-firmware subdevice since smmu is not expected to provide access control/translation for these SIDs (sandboxing of the modem is achieved through XPUs engaged using SMC calls). So the DMA accesses are initiated by the firmware and need to be direct mapped? Which memory region do they access? The accesses are initiated by the firmware and they access modem reserved regions. However as explained in ^^ any accesses outside the region will result in a violation and is controlled through XPUs (protection units). With ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT y the firmware SIDs will explicitly need to be directly mapped to avoid observing global faults in the absence of secure firmware (TrustZone) programming the modem SIDs as S2CR-Bypass. Regards, Joerg -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/3] dt-bindings: remoteproc: qcom: Add modem-firmware bindings
Introduce modem-firmware binding to allow Q6 modem to boot on platforms which do not have trustZone. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 88dfa3fc15f78..b1715bc90fb05 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -198,6 +198,10 @@ The Hexagon node may also have an subnode named either "smd-edge" or related to the Hexagon. See ../soc/qcom/qcom,smd.txt and ../soc/qcom/qcom,glink.txt for details on how to describe these. +The Hexagon node must contain a subnode named "modem-firmware" on +platforms which do not have TrustZone. The sub-node should have the +iommu property as described in ../iommu/iommu.txt. + = EXAMPLE The following example describes the resources needed to boot control the Hexagon, as it is found on MSM8974 boards. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 3/3] remoteproc: qcom_q6v5_mss: Request direct mapping for firmware subdevice
The Q6 modem sub-system has direct access to DDR through memnoc and
an indirect access routed through a SMMU which MSS CE (crypto engine
sub-component of MSS) uses during out of reset sequence. Request direct
mapping for the modem-firmware subdevice since smmu is not expected
to provide access control/translation for these SIDs (sandboxing of the
modem is achieved through XPUs engaged using SMC calls).
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/qcom_q6v5_mss.c | 68 ++
1 file changed, 68 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index d7667418a62f4..ceb7f71dd17df 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -202,6 +203,7 @@ struct q6v5 {
struct qcom_rproc_subdev smd_subdev;
struct qcom_rproc_ssr ssr_subdev;
struct qcom_sysmon *sysmon;
+ struct device *fw_subdev;
bool need_mem_protection;
bool has_alt_reset;
bool has_halt_nav;
@@ -378,6 +380,67 @@ static void q6v5_pds_disable(struct q6v5 *qproc, struct
device **pds,
}
}
+static int qcom_init_firmware(struct q6v5 *qproc)
+{
+ struct platform_device_info info;
+ struct platform_device *pdev;
+ struct device_node *np;
+ int ret;
+
+ np = of_get_child_by_name(qproc->dev->of_node, "modem-firmware");
+ if (!np)
+ return 0;
+
+ memset(&info, 0, sizeof(info));
+ info.fwnode = &np->fwnode;
+ info.parent = qproc->dev;
+ info.name = np->name;
+
+ pdev = platform_device_register_full(&info);
+ if (IS_ERR(pdev)) {
+ of_node_put(np);
+ return PTR_ERR(pdev);
+ }
+
+ pdev->dev.of_node = np;
+ ret = of_dma_configure(&pdev->dev, np, true);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to configure DMA\n");
+ goto err_unregister;
+ }
+
+ ret = iommu_request_dm_for_dev(&pdev->dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request direct mapping\n");
+ goto err_unregister;
+ }
+
+ qproc->fw_subdev = &pdev->dev;
+ of_node_put(np);
+ return 0;
+
+err_unregister:
+ platform_device_unregister(pdev);
+ of_node_put(np);
+ return ret;
+}
+
+static void qcom_remove_firmware(struct q6v5 *qproc)
+{
+ struct iommu_domain *iommu;
+
+ if (!qproc->fw_subdev)
+ return;
+
+ iommu = iommu_get_domain_for_dev(qproc->fw_subdev);
+ if (!iommu)
+ return;
+
+ iommu_detach_device(iommu, qproc->fw_subdev);
+ iommu_domain_free(iommu);
+ platform_device_unregister(to_platform_device(qproc->fw_subdev));
+}
+
static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
bool local, bool remote, phys_addr_t addr,
size_t size)
@@ -1722,6 +1785,10 @@ static int q6v5_probe(struct platform_device *pdev)
if (ret)
goto detach_proxy_pds;
+ ret = qcom_init_firmware(qproc);
+ if (ret)
+ goto detach_proxy_pds;
+
qproc->mpss_perm = BIT(QCOM_SCM_VMID_HLOS);
qproc->mba_perm = BIT(QCOM_SCM_VMID_HLOS);
qcom_add_glink_subdev(rproc, &qproc->glink_subdev);
@@ -1759,6 +1826,7 @@ static int q6v5_remove(struct platform_device *pdev)
qcom_remove_glink_subdev(qproc->rproc, &qproc->glink_subdev);
qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
+ qcom_remove_firmware(qproc);
q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/3] iommu: Export "iommu_request_dm_for_dev"
Export "iommu_request_dm_for_dev" to allow for modular builds of
drivers requesting for direct mapping.
Signed-off-by: Sibi Sankar
---
drivers/iommu/iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3e3528436e0b2..06a36230fe22d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2353,6 +2353,7 @@ int iommu_request_dm_for_dev(struct device *dev)
{
return request_default_domain_for_dev(dev, IOMMU_DOMAIN_IDENTITY);
}
+EXPORT_SYMBOL_GPL(iommu_request_dm_for_dev);
/* Request that a device can't be direct mapped by the IOMMU */
int iommu_request_dma_domain_for_dev(struct device *dev)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 0/3] Request direct mapping for modem firmware subdevice
The Q6 modem sub-system has direct access to DDR through memnoc and an indirect access routed through a SMMU which MSS CE (crypto engine sub-component of MSS) uses during out of reset sequence. Request direct mapping for the modem-firmware subdevice since smmu is not expected to provide access control/translation for these SIDs (sandboxing of the modem is achieved through XPUs engaged using SMC calls). Sibi Sankar (3): iommu: Export "iommu_request_dm_for_dev" dt-bindings: remoteproc: qcom: Add modem-firmware bindings remoteproc: qcom_q6v5_mss: Request direct mapping for firmware subdevice .../bindings/remoteproc/qcom,q6v5.txt | 4 ++ drivers/iommu/iommu.c | 1 + drivers/remoteproc/qcom_q6v5_mss.c| 68 +++ 3 files changed, 73 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
