diff mbox series

[v9,5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Message ID 20180313085534.11650-6-vivek.gautam@codeaurora.org
State Superseded, archived
Headers show
Series iommu/arm-smmu: Add runtime pm/sleep support | expand

Commit Message

Vivek Gautam March 13, 2018, 8:55 a.m. UTC 
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 <vivek.gautam@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
---
 .../devicetree/bindings/iommu/arm,smmu.txt         | 42 ++++++++++++++++++++++
 drivers/iommu/arm-smmu.c                           | 14 ++++++++
 2 files changed, 56 insertions(+)

Comments

Yisheng Xie March 28, 2018, 6:11 a.m. UTC | #1 
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
Tomasz Figa April 10, 2018, 1:14 p.m. UTC | #2 
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
Yisheng Xie April 11, 2018, 1:22 a.m. UTC | #3 
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
Vivek Gautam April 11, 2018, 5:15 a.m. UTC | #4 
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
Yisheng Xie April 12, 2018, 1:55 a.m. UTC | #5 
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 mbox series

Patch

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>");