| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20200109002606.35653-1-masneyb@onstation.org>
Date: Wed, 8 Jan 2020 19:26:06 -0500
From: Brian Masney <masneyb@...tation.org>
To: robdclark@...il.com, bjorn.andersson@...aro.org
Cc: agross@...nel.org, joro@...tes.org, linux-arm-msm@...r.kernel.org,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
freedreno@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: [PATCH RFC] ARM: dts: qcom: msm8974: add mdp5 iommu support
This adds preliminary IOMMU support for the MDP5 on msm8974. It appears
that the qcom-iommu driver in upstream can be used on this SoC. I marked
this patch as a RFC since the frame buffer becomes corrupted when I boot
the Nexus 5 phone with this patch:
https://raw.githubusercontent.com/masneyb/nexus-5-upstream/master/images/broken-mdp5-iommu.jpg
A quick note about the ranges of the context banks below: Based on the
downstream sources, I believe that the memory addresses should be mapped
out like this:
mdp_iommu: iommu@...28000 {
reg = <0xfd928000 0x8000>;
ranges = <0 0xfd930000 0x8000>;
...
iommu-ctx@0 {
reg = <0x0 0x1000>;
...
};
iommu-ctx@...0 {
reg = <0x1000 0x1000>;
...
};
iommu-ctx@...0 {
reg = <0x2000 0x1000>;
...
};
};
However, the qcom-iommu driver in upstream expects the first context
bank to exist at address 0x1000, and the address space identifier
(asid) to be greater than 0. See get_asid() and qcom_iommu_of_xlate()
in the upstream qcom-iommu.c driver. I put in the patch below what the
driver expects. I modified the driver in my local tree to allow the
mapping that I have above so that the extra 0x1000 of memory is mapped
into the global address space and still experience the same screen
corruption issue.
Downstream MSM 3.4 IOMMU dts snippet for reference:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm-iommu-v1.dtsi#L110
I'm hoping that someone that's more familiar with this hardware has a
suggestion for something to try.
Signed-off-by: Brian Masney <masneyb@...tation.org>
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 44 +++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 4b161b809dd5..2515a3bd4aa7 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1305,6 +1305,46 @@ etm3_out: endpoint {
};
};
+ mdp_iommu: iommu@...28000 {
+ compatible = "qcom,msm8974-iommu",
+ "qcom,msm-iommu-v1";
+ reg = <0xfd928000 0x7000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #iommu-cells = <1>;
+ ranges = <0 0xfd92f000 0x9000>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+ <&mmcc MDSS_AXI_CLK>;
+ clock-names = "iface",
+ "bus";
+
+ qcom,iommu-secure-id = <1>;
+
+ // mdp_0
+ iommu-ctx@...0 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x1000 0x1000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ // mdp_1
+ iommu-ctx@...0 {
+ compatible = "qcom,msm-iommu-v1-sec";
+ reg = <0x2000 0x1000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ // mdp_2
+ iommu-ctx@...0 {
+ compatible = "qcom,msm-iommu-v1-sec";
+ reg = <0x3000 0x1000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
ocmem@...00000 {
compatible = "qcom,msm8974-ocmem";
reg = <0xfdd00000 0x2000>,
@@ -1427,6 +1467,10 @@ mdp: mdp@...00000 {
interconnects = <&mmssnoc MNOC_MAS_MDP_PORT0 &bimc BIMC_SLV_EBI_CH0>;
interconnect-names = "mdp0-mem";
+ iommus = <&mdp_iommu 1
+ &mdp_iommu 2
+ &mdp_iommu 3>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.24.1
Powered by blists - more mailing lists