Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
Hi Vivek, On 2018/4/11 13:15, Vivek Gautam wrote: > Hi Yisheng, > > > On 4/11/2018 6:52 AM, Yisheng Xie wrote: >> Hi Tomasz, >> >> On 2018/4/10 21:14, Tomasz Figa wrote: >>> Hi Yisheng, >>> >>> Sorry, I think we missed your question here. >>> >>> On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: >>> Hi Vivek, On 2018/3/28 12:37, Vivek Gautam wrote: > Hi Yisheng > > > On 3/28/2018 6:54 AM, Yisheng Xie wrote: >> Hi Vivek, >> >> On 2018/3/13 16:55, Vivek Gautam wrote: >>> +- power-domains: Specifiers for power domains required to be >>> powered on for >>> + the SMMU to operate, as per generic power domain >>> bindings. >>> + >> In this patchset, power-domains is not used right? And you just do the >>> clock gating, >> but not power gating, right? > We are handling the power-domains too. Please see the example in this >>> binding doc. >>> I see, but I do not find the point in code of these patchset, do you mean >>> PMIC(e.g mmcc) will gate the power domain of SMMU(e.g. MDSS_GDSC of mmcc) when PMIC >>> suspend? >>> >>> >>> If respective SoC power domains is registered as a standard genpd PM >>> domain, then the runtime PM subsystem will take care of power domain >>> control at runtime suspend and resume. >>> >> Get it, thanks for your explain, I should have learned about this. > > Sorry, i missed your subsequent question, and Tomasz has explained it now. Never mind about that. > Let me know if you have further questions. Presently, no other questions. Thanks for your kind help. Thanks Yisheng > > regards > Vivek >> >> Thanks >> Yisheng >> >>> Best regards, >>> Tomasz >>> >>> . >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > . >
Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
Hi Yisheng, On 4/11/2018 6:52 AM, Yisheng Xie wrote: Hi Tomasz, On 2018/4/10 21:14, Tomasz Figa wrote: Hi Yisheng, Sorry, I think we missed your question here. On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: Hi Vivek, On 2018/3/28 12:37, Vivek Gautam wrote: Hi Yisheng On 3/28/2018 6:54 AM, Yisheng Xie wrote: Hi Vivek, On 2018/3/13 16:55, Vivek Gautam wrote: +- power-domains: Specifiers for power domains required to be powered on for + the SMMU to operate, as per generic power domain bindings. + In this patchset, power-domains is not used right? And you just do the clock gating, but not power gating, right? We are handling the power-domains too. Please see the example in this binding doc. I see, but I do not find the point in code of these patchset, do you mean PMIC(e.g mmcc) will gate the power domain of SMMU(e.g. MDSS_GDSC of mmcc) when PMIC suspend? If respective SoC power domains is registered as a standard genpd PM domain, then the runtime PM subsystem will take care of power domain control at runtime suspend and resume. Get it, thanks for your explain, I should have learned about this. Sorry, i missed your subsequent question, and Tomasz has explained it now. Let me know if you have further questions. regards Vivek Thanks Yisheng Best regards, Tomasz . -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
Hi Tomasz, On 2018/4/10 21:14, Tomasz Figa wrote: > Hi Yisheng, > > Sorry, I think we missed your question here. > > On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: > >> Hi Vivek, > >> On 2018/3/28 12:37, Vivek Gautam wrote: >>> Hi Yisheng >>> >>> >>> On 3/28/2018 6:54 AM, Yisheng Xie wrote: Hi Vivek, On 2018/3/13 16:55, Vivek Gautam wrote: > +- power-domains: Specifiers for power domains required to be > powered on for > + the SMMU to operate, as per generic power domain > bindings. > + In this patchset, power-domains is not used right? And you just do the > clock gating, but not power gating, right? >>> >>> We are handling the power-domains too. Please see the example in this > binding doc. > >> I see, but I do not find the point in code of these patchset, do you mean > PMIC(e.g mmcc) >> will gate the power domain of SMMU(e.g. MDSS_GDSC of mmcc) when PMIC > suspend? > > > If respective SoC power domains is registered as a standard genpd PM > domain, then the runtime PM subsystem will take care of power domain > control at runtime suspend and resume. > Get it, thanks for your explain, I should have learned about this. Thanks Yisheng > Best regards, > Tomasz > > . >
Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
Hi Yisheng, Sorry, I think we missed your question here. On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: > Hi Vivek, > On 2018/3/28 12:37, Vivek Gautam wrote: > > Hi Yisheng > > > > > > On 3/28/2018 6:54 AM, Yisheng Xie wrote: > >> Hi Vivek, > >> > >> On 2018/3/13 16:55, Vivek Gautam wrote: > >>> +- power-domains: Specifiers for power domains required to be powered on for > >>> + the SMMU to operate, as per generic power domain bindings. > >>> + > >> In this patchset, power-domains is not used right? And you just do the clock gating, > >> but not power gating, right? > > > > We are handling the power-domains too. Please see the example in this binding doc. > I see, but I do not find the point in code of these patchset, do you mean PMIC(e.g mmcc) > will gate the power domain of SMMU(e.g. MDSS_GDSC of mmcc) when PMIC suspend? If respective SoC power domains is registered as a standard genpd PM domain, then the runtime PM subsystem will take care of power domain control at runtime suspend and resume. Best regards, Tomasz
Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
Hi Vivek, On 2018/3/28 12:37, Vivek Gautam wrote: > Hi Yisheng > > > On 3/28/2018 6:54 AM, Yisheng Xie wrote: >> Hi Vivek, >> >> On 2018/3/13 16:55, Vivek Gautam wrote: >>> +- power-domains: Specifiers for power domains required to be powered on >>> for >>> + the SMMU to operate, as per generic power domain >>> bindings. >>> + >> In this patchset, power-domains is not used right? And you just do the clock >> gating, >> but not power gating, right? > > We are handling the power-domains too. Please see the example in this binding > doc. I see, but I do not find the point in code of these patchset, do you mean PMIC(e.g mmcc) will gate the power domain of SMMU(e.g. MDSS_GDSC of mmcc) when PMIC suspend? > >> >> Another question is if smmu do power gating, it will reset some of its >> registers, so >> it need save at suspend and restore at resume, right? > > Qualcomm implementation of the arm-smmu has the retenetion enabled. So the > smmu doesn't > loose state when power is pulled out of it. > And now we are just selectively enabling the runtime pm. So only the > platforms that can really > support runtime pm can enable it. Get it, thanks for your explain. Thanks Yisheng > > Thanks > Vivek >> >> Thanks >> Yisheng >> > > >
[PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. This smmu core is used with multiple masters on msm8996, viz. mdss, video, etc. Add bindings for the same. Signed-off-by: Vivek Gautam Reviewed-by: Rob Herring Reviewed-by: Tomasz Figa --- .../devicetree/bindings/iommu/arm,smmu.txt | 42 ++ drivers/iommu/arm-smmu.c | 14 2 files changed, 56 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt index 8a6ffce12af5..7c71a6ed465a 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -17,10 +17,19 @@ conditions. "arm,mmu-401" "arm,mmu-500" "cavium,smmu-v2" +"qcom,-smmu-v2", "qcom,smmu-v2" depending on the particular implementation and/or the version of the architecture implemented. + A number of Qcom SoCs use qcom,smmu-v2 version of the IP. + "qcom,-smmu-v2" represents a soc specific compatible + string that should be present along with the "qcom,smmu-v2" + to facilitate SoC specific clocks/power connections and to + address specific bug fixes. + An example string would be - + "qcom,msm8996-smmu-v2", "qcom,smmu-v2". + - reg : Base address and size of the SMMU. - #global-interrupts : The number of global interrupts exposed by the @@ -71,6 +80,22 @@ conditions. or using stream matching with #iommu-cells = <2>, and may be ignored if present in such cases. +- clock-names:List of the names of clocks input to the device. The + required list depends on particular implementation and + is as follows: + - for "qcom,smmu-v2": +- "bus": clock required for downstream bus access and + for the smmu ptw, +- "iface": clock required to access smmu's registers + through the TCU's programming interface. + - unspecified for other implementations. + +- clocks: Specifiers for all clocks listed in the clock-names property, + as per generic clock bindings. + +- power-domains: Specifiers for power domains required to be powered on for + the SMMU to operate, as per generic power domain bindings. + ** Deprecated properties: - mmu-masters (deprecated in favour of the generic "iommus" binding) : @@ -137,3 +162,20 @@ conditions. iommu-map = <0 &smmu3 0 0x400>; ... }; + + /* Qcom's arm,smmu-v2 implementation */ + smmu4: iommu { + compatible = "qcom,msm8996-smmu-v2", "qcom,smmu-v2"; + reg = <0xd0 0x1>; + + #global-interrupts = <1>; + interrupts = , +, +; + #iommu-cells = <1>; + power-domains = <&mmcc MDSS_GDSC>; + + clocks = <&mmcc SMMU_MDP_AXI_CLK>, +<&mmcc SMMU_MDP_AHB_CLK>; + clock-names = "bus", "iface"; + }; diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 64953ff2281f..1ef6ac56a347 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -119,6 +119,7 @@ enum arm_smmu_implementation { GENERIC_SMMU, ARM_MMU500, CAVIUM_SMMUV2, + QCOM_SMMUV2, }; struct arm_smmu_s2cr { @@ -2000,6 +2001,17 @@ ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, GENERIC_SMMU); ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500); ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2); +static const char * const qcom_smmuv2_clks[] = { + "bus", "iface", +}; + +static const struct arm_smmu_match_data qcom_smmuv2 = { + .version = ARM_SMMU_V2, + .model = QCOM_SMMUV2, + .clks = qcom_smmuv2_clks, + .num_clks = ARRAY_SIZE(qcom_smmuv2_clks), +}; + static const struct of_device_id arm_smmu_of_match[] = { { .compatible = "arm,smmu-v1", .data = &smmu_generic_v1 }, { .compatible = "arm,smmu-v2", .data = &smmu_generic_v2 }, @@ -2007,6 +2019,7 @@ static const struct of_device_id arm_smmu_of_match[] = { { .compatible = "arm,mmu-401", .data = &arm_mmu401 }, { .compatible = "arm,mmu-500", .data = &arm_mmu500 }, { .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 }, + { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 }, { }, }; MODULE_DEVICE_TABLE(of, arm_smmu_of_match); @@ -2381,6 +2394,7 @@ IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400"); IOMMU_OF_DECLARE(arm_mmu401, "