| Message ID | 20170525174822.27996-4-robdclark@gmail.com (mailing list archive) |
|---|---|
| State | Deferred |
| Delegated to: | Andy Gross |
| Headers | show |
On 05/25, Rob Clark wrote: > + apps_iommu: iommu@1ef0000 { > + #address-cells = <1>; > + #size-cells = <1>; > + #iommu-cells = <1>; > + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; > + ranges = <0 0x1e20000 0x40000>; > + reg = <0x1ef0000 0x3000>; > + clocks = <&gcc GCC_SMMU_CFG_CLK>, > + <&gcc GCC_APSS_TCU_CLK>; > + clock-names = "iface", "bus"; > + qcom,iommu-secure-id = <17>; > + > + // mdp_0: > + iommu-ctx@4000 { > + compatible = "qcom,msm-iommu-v1-ns"; > + reg = <0x4000 0x1000>; > + interrupts = <GIC_SPI 70 0>; s/0/IRQ_TYPE_LEVEL_HIGH/ > + }; > + > + // venus_ns: > + iommu-ctx@5000 { > + compatible = "qcom,msm-iommu-v1-sec"; > + reg = <0x5000 0x1000>; > + interrupts = <GIC_SPI 70 0>; s/0/IRQ_TYPE_LEVEL_HIGH/ Is it the same interrupt number (70) twice? Not 71 or something? > + }; > + }; > + > + gpu_iommu: iommu@1f08000 { > + #address-cells = <1>; > + #size-cells = <1>; > + #iommu-cells = <1>; > + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; > + ranges = <0 0x1f08000 0x10000>; > + clocks = <&gcc GCC_SMMU_CFG_CLK>, > + <&gcc GCC_GFX_TCU_CLK>; > + clock-names = "iface", "bus"; > + qcom,iommu-secure-id = <18>; > + > + // gfx3d_user: > + iommu-ctx@1000 { > + compatible = "qcom,msm-iommu-v1-ns"; > + reg = <0x1000 0x1000>; > + interrupts = <GIC_SPI 241 0>; s/0/IRQ_TYPE_LEVEL_HIGH/ > + }; > + > + // gfx3d_priv: > + iommu-ctx@2000 { > + compatible = "qcom,msm-iommu-v1-ns"; > + reg = <0x2000 0x1000>; > + interrupts = <GIC_SPI 242 0>; s/0/IRQ_TYPE_LEVEL_HIGH/ > + }; > + }; > + > gpu_opp_table: opp_table { > compatible = "operating-points-v2"; >
On Tue, May 30, 2017 at 8:14 PM, Stephen Boyd <sboyd@codeaurora.org> wrote: > On 05/25, Rob Clark wrote: >> + apps_iommu: iommu@1ef0000 { >> + #address-cells = <1>; >> + #size-cells = <1>; >> + #iommu-cells = <1>; >> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; >> + ranges = <0 0x1e20000 0x40000>; >> + reg = <0x1ef0000 0x3000>; >> + clocks = <&gcc GCC_SMMU_CFG_CLK>, >> + <&gcc GCC_APSS_TCU_CLK>; >> + clock-names = "iface", "bus"; >> + qcom,iommu-secure-id = <17>; >> + >> + // mdp_0: >> + iommu-ctx@4000 { >> + compatible = "qcom,msm-iommu-v1-ns"; >> + reg = <0x4000 0x1000>; >> + interrupts = <GIC_SPI 70 0>; > > s/0/IRQ_TYPE_LEVEL_HIGH/ 0 actually seems to be _NONE.. so using _HIGH would change how irq is configured (according to gic_configure_irq()). Do you expect that to work? I'm probably going based on what was in downstream dt, and some of that is more a pain to retest so I'd rather not change the type unless at least one of us knows what they are doing. >> + }; >> + >> + // venus_ns: >> + iommu-ctx@5000 { >> + compatible = "qcom,msm-iommu-v1-sec"; >> + reg = <0x5000 0x1000>; >> + interrupts = <GIC_SPI 70 0>; > > s/0/IRQ_TYPE_LEVEL_HIGH/ > > Is it the same interrupt number (70) twice? Not 71 or something? According to downstream. Not *entirely* sure how that is supposed to work as far as dispatching fault callback to the right driver, but at least unlike with the gpu, if we get a fault for mdp, that is entirely the kernels fault. So meh? If you know better, let me know. BR, -R > >> + }; >> + }; >> + >> + gpu_iommu: iommu@1f08000 { >> + #address-cells = <1>; >> + #size-cells = <1>; >> + #iommu-cells = <1>; >> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; >> + ranges = <0 0x1f08000 0x10000>; >> + clocks = <&gcc GCC_SMMU_CFG_CLK>, >> + <&gcc GCC_GFX_TCU_CLK>; >> + clock-names = "iface", "bus"; >> + qcom,iommu-secure-id = <18>; >> + >> + // gfx3d_user: >> + iommu-ctx@1000 { >> + compatible = "qcom,msm-iommu-v1-ns"; >> + reg = <0x1000 0x1000>; >> + interrupts = <GIC_SPI 241 0>; > > s/0/IRQ_TYPE_LEVEL_HIGH/ > >> + }; >> + >> + // gfx3d_priv: >> + iommu-ctx@2000 { >> + compatible = "qcom,msm-iommu-v1-ns"; >> + reg = <0x2000 0x1000>; >> + interrupts = <GIC_SPI 242 0>; > > s/0/IRQ_TYPE_LEVEL_HIGH/ > >> + }; >> + }; >> + >> gpu_opp_table: opp_table { >> compatible = "operating-points-v2"; >> > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/31, Rob Clark wrote: > On Tue, May 30, 2017 at 8:14 PM, Stephen Boyd <sboyd@codeaurora.org> wrote: > > On 05/25, Rob Clark wrote: > >> + apps_iommu: iommu@1ef0000 { > >> + #address-cells = <1>; > >> + #size-cells = <1>; > >> + #iommu-cells = <1>; > >> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; > >> + ranges = <0 0x1e20000 0x40000>; > >> + reg = <0x1ef0000 0x3000>; > >> + clocks = <&gcc GCC_SMMU_CFG_CLK>, > >> + <&gcc GCC_APSS_TCU_CLK>; > >> + clock-names = "iface", "bus"; > >> + qcom,iommu-secure-id = <17>; > >> + > >> + // mdp_0: > >> + iommu-ctx@4000 { > >> + compatible = "qcom,msm-iommu-v1-ns"; > >> + reg = <0x4000 0x1000>; > >> + interrupts = <GIC_SPI 70 0>; > > > > s/0/IRQ_TYPE_LEVEL_HIGH/ > > 0 actually seems to be _NONE.. so using _HIGH would change how irq is > configured (according to gic_configure_irq()). Do you expect that to > work? I'm probably going based on what was in downstream dt, and some > of that is more a pain to retest so I'd rather not change the type > unless at least one of us knows what they are doing. I believe the default setting for all these interrupts are IRQ_TYPE_LEVEL_HIGH already, so there shouldn't be any change to behavior and things should still work. Would be worth double checking what the GIC has it configured as with IRQ_TYPE_NONE here by looking at /proc/interrupts. I suspect it's level high. > > >> + }; > >> + > >> + // venus_ns: > >> + iommu-ctx@5000 { > >> + compatible = "qcom,msm-iommu-v1-sec"; > >> + reg = <0x5000 0x1000>; > >> + interrupts = <GIC_SPI 70 0>; > > > > s/0/IRQ_TYPE_LEVEL_HIGH/ > > > > Is it the same interrupt number (70) twice? Not 71 or something? > > According to downstream. Not *entirely* sure how that is supposed to > work as far as dispatching fault callback to the right driver, but at > least unlike with the gpu, if we get a fault for mdp, that is entirely > the kernels fault. So meh? > > If you know better, let me know. > Ok, I see what's going on. This design still seems odd to me. We have an interrupt per-context bank in DT so that we can map the top-level aggregated context bank interrupt (70) to each context bank that has their interrupt routed there. Depending on the bootloader configuration we could have many context banks route their fault interrupt to the same interrupt at the GIC or they could go to different top-level interrupts. In the GFX IOMMU case, hw folks decided to _not_ aggregate context bank interrupts at all so each context bank has a dedicated interrupt at the GIC.
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index 2ef8f53..13bb079 100644 --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -705,6 +705,59 @@ #thermal-sensor-cells = <1>; }; + apps_iommu: iommu@1ef0000 { + #address-cells = <1>; + #size-cells = <1>; + #iommu-cells = <1>; + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; + ranges = <0 0x1e20000 0x40000>; + reg = <0x1ef0000 0x3000>; + clocks = <&gcc GCC_SMMU_CFG_CLK>, + <&gcc GCC_APSS_TCU_CLK>; + clock-names = "iface", "bus"; + qcom,iommu-secure-id = <17>; + + // mdp_0: + iommu-ctx@4000 { + compatible = "qcom,msm-iommu-v1-ns"; + reg = <0x4000 0x1000>; + interrupts = <GIC_SPI 70 0>; + }; + + // venus_ns: + iommu-ctx@5000 { + compatible = "qcom,msm-iommu-v1-sec"; + reg = <0x5000 0x1000>; + interrupts = <GIC_SPI 70 0>; + }; + }; + + gpu_iommu: iommu@1f08000 { + #address-cells = <1>; + #size-cells = <1>; + #iommu-cells = <1>; + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; + ranges = <0 0x1f08000 0x10000>; + clocks = <&gcc GCC_SMMU_CFG_CLK>, + <&gcc GCC_GFX_TCU_CLK>; + clock-names = "iface", "bus"; + qcom,iommu-secure-id = <18>; + + // gfx3d_user: + iommu-ctx@1000 { + compatible = "qcom,msm-iommu-v1-ns"; + reg = <0x1000 0x1000>; + interrupts = <GIC_SPI 241 0>; + }; + + // gfx3d_priv: + iommu-ctx@2000 { + compatible = "qcom,msm-iommu-v1-ns"; + reg = <0x2000 0x1000>; + interrupts = <GIC_SPI 242 0>; + }; + }; + gpu_opp_table: opp_table { compatible = "operating-points-v2"; @@ -738,6 +791,7 @@ <&gcc GFX3D_CLK_SRC>; power-domains = <&gcc OXILI_GDSC>; operating-points-v2 = <&gpu_opp_table>; + iommus = <&gpu_iommu 1>, <&gpu_iommu 2>; }; mdss: mdss@1a00000 { @@ -781,6 +835,8 @@ "core_clk", "vsync_clk"; + iommus = <&apps_iommu 4>; + ports { #address-cells = <1>; #size-cells = <0>; @@ -1231,6 +1287,7 @@ <&gcc GCC_VENUS0_AHB_CLK>, <&gcc GCC_VENUS0_AXI_CLK>; clock-names = "core", "iface", "bus"; + iommus = <&apps_iommu 5>; memory-region = <&venus_mem>; status = "okay";
Signed-off-by: Rob Clark <robdclark@gmail.com> --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 57 +++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+)