Message ID | 20180313085534.11650-6-vivek.gautam@codeaurora.org |
---|---|
State | Superseded, archived |
Headers | show |
Series | iommu/arm-smmu: Add runtime pm/sleep support | expand |
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 >> > > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Yisheng, Sorry, I think we missed your question here. On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie <xieyisheng1@huawei.com> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <xieyisheng1@huawei.com> 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 > > . > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <xieyisheng1@huawei.com> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <xieyisheng1@huawei.com> 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 majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > . > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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,<soc>-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,<soc>-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 = <0xd00000 0x10000>; + + #global-interrupts = <1>; + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>; + #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, "arm,mmu-401"); IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500"); IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2"); +IOMMU_OF_DECLARE(qcom_smmuv2, "qcom,smmu-v2"); MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations"); MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");