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

2018-04-11 Thread Yisheng Xie 
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
> 
> 
> .
> 

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2018-04-10 Thread Vivek Gautam 

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


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2018-04-10 Thread Yisheng Xie 
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
> 
> .
> 

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2018-04-10 Thread Tomasz Figa 
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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2018-03-28 Thread Yisheng Xie 
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
>>
> 
> 
> 

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2018-03-13 Thread Vivek Gautam 
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  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 = < MDSS_GDSC>;
+
+   clocks = < SMMU_MDP_AXI_CLK>,
+< 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 = _generic_v1 },
{ .compatible = "arm,smmu-v2", .data = _generic_v2 },
@@ -2007,6 +2019,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,mmu-401", .data = _mmu401 },
{ .compatible = "arm,mmu-500", .data = _mmu500 },
{ .compatible = "cavium,smmu-v2", .data = _smmuv2 },
+   { .compatible = "qcom,smmu-v2", .data = _smmuv2 },
{ },
 };
 MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
@@ -2381,6 +2394,7 @@ IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");