[PATCH 0/2] clk: qcom: gcc: Add support to child devices.

[PATCH 0/2] clk: qcom: gcc: Add support to child devices.

[Srinivas Kandagatla]

This patchset adds support to child devices whose memory registers fall
insider gcc memory map.
For example on APQ8064 whose thermal sensor registers are inside gcc memory range.

Thanks,
srini

Srinivas Kandagatla (2):
  clk: qcom: gcc-msm8960: add child devices support.
  clk: qcom: gcc bindings: Update to add child node support.

 Documentation/devicetree/bindings/clock/qcom,gcc.txt | 5 +++++
 drivers/clk/qcom/gcc-msm8960.c                       | 7 ++++++-
 2 files changed, 11 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Srinivas Kandagatla]

This patch adds support to add child devices to gcc as some of the
registers mapped by gcc are used by drivers like thermal sensors.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/clk/qcom/gcc-msm8960.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
index 0cd3e26..2315b64 100644
--- a/drivers/clk/qcom/gcc-msm8960.c
+++ b/drivers/clk/qcom/gcc-msm8960.c
@@ -15,6 +15,7 @@
 #include <linux/bitops.h>
 #include <linux/err.h>
 #include <linux/platform_device.h>
+#include <linux/of_platform.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
@@ -3677,12 +3678,16 @@ static int gcc_msm8960_probe(struct platform_device *pdev)
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
-	return qcom_cc_probe(pdev, match->data);
+	qcom_cc_probe(pdev, match->data);
+
+	return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
 }
 
 static int gcc_msm8960_remove(struct platform_device *pdev)
 {
 	qcom_cc_remove(pdev);
+	of_platform_depopulate(&pdev->dev);
+
 	return 0;
 }
 
-- 
1.9.1

[PATCH 2/2] clk: qcom: gcc bindings: Update to add child node support.

[Srinivas Kandagatla]

This patch adds note in the bindings about the optional child nodes
which are currently possible with SOCs like MSM8960, APQ8064.
These child device nodes are typically for drivers like thermal sensor
which fall under the memory-map of gcc.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/clock/qcom,gcc.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index aba3d25..c79225b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -17,6 +17,11 @@ Required properties :
 - #clock-cells : shall contain 1
 - #reset-cells : shall contain 1
 
+Optional child nodes:
+	Child nodes could be any device nodes with its own bindings which
+	fall inside the memory-map of the Clock controller, for example
+	thermal sensor driver.
+
 Example:
 	clock-controller@900000 {
 		compatible = "qcom,gcc-msm8960";
-- 
1.9.1

[PATCH v2 0/2] clk: qcom: gcc: Add support to child devices.

[Srinivas Kandagatla]

This patchset adds support to child devices whose memory registers fall
insider gcc memory map.
For example on APQ8064 whose thermal sensor registers are inside gcc memory range.

Changes since v1:
	- Check return value of qcom_cc_probe spotted by Pramod.

Thanks,
srini

Srinivas Kandagatla (2):
  clk: qcom: gcc-msm8960: add child devices support.
  clk: qcom: gcc bindings: Update to add child node support.

 Documentation/devicetree/bindings/clock/qcom,gcc.txt |  5 +++++
 drivers/clk/qcom/gcc-msm8960.c                       | 10 +++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Srinivas Kandagatla]

This patch adds support to add child devices to gcc as some of the
registers mapped by gcc are used by drivers like thermal sensors.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/clk/qcom/gcc-msm8960.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
index 0cd3e26..3ba77c5 100644
--- a/drivers/clk/qcom/gcc-msm8960.c
+++ b/drivers/clk/qcom/gcc-msm8960.c
@@ -15,6 +15,7 @@
 #include <linux/bitops.h>
 #include <linux/err.h>
 #include <linux/platform_device.h>
+#include <linux/of_platform.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
@@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct platform_device *pdev)
 	struct clk *clk;
 	struct device *dev = &pdev->dev;
 	const struct of_device_id *match;
+	int ret;
 
 	match = of_match_device(gcc_msm8960_match_table, &pdev->dev);
 	if (!match)
@@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct platform_device *pdev)
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
-	return qcom_cc_probe(pdev, match->data);
+	ret = qcom_cc_probe(pdev, match->data);
+	if (ret)
+		return ret;
+
+	return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
 }
 
 static int gcc_msm8960_remove(struct platform_device *pdev)
 {
 	qcom_cc_remove(pdev);
+	of_platform_depopulate(&pdev->dev);
+
 	return 0;
 }
 
-- 
1.9.1

[PATCH v2 2/2] clk: qcom: gcc bindings: Update to add child node support.

[Srinivas Kandagatla]

This patch adds note in the bindings about the optional child nodes
which are currently possible with SOCs like MSM8960, APQ8064.
These child device nodes are typically for drivers like thermal sensor
which fall under the memory-map of gcc.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/clock/qcom,gcc.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index aba3d25..c79225b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -17,6 +17,11 @@ Required properties :
 - #clock-cells : shall contain 1
 - #reset-cells : shall contain 1
 
+Optional child nodes:
+	Child nodes could be any device nodes with its own bindings which
+	fall inside the memory-map of the Clock controller, for example
+	thermal sensor driver.
+
 Example:
 	clock-controller@900000 {
 		compatible = "qcom,gcc-msm8960";
-- 
1.9.1

Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Bjorn Andersson]

On Fri, Jan 30, 2015 at 2:17 AM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> This patch adds support to add child devices to gcc as some of the
> registers mapped by gcc are used by drivers like thermal sensors.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  drivers/clk/qcom/gcc-msm8960.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
> index 0cd3e26..3ba77c5 100644
> --- a/drivers/clk/qcom/gcc-msm8960.c
> +++ b/drivers/clk/qcom/gcc-msm8960.c
> @@ -15,6 +15,7 @@
>  #include <linux/bitops.h>
>  #include <linux/err.h>
>  #include <linux/platform_device.h>
> +#include <linux/of_platform.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_device.h>
> @@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct platform_device *pdev)
>         struct clk *clk;
>         struct device *dev = &pdev->dev;
>         const struct of_device_id *match;
> +       int ret;
>
>         match = of_match_device(gcc_msm8960_match_table, &pdev->dev);
>         if (!match)
> @@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct platform_device *pdev)
>         if (IS_ERR(clk))
>                 return PTR_ERR(clk);
>
> -       return qcom_cc_probe(pdev, match->data);
> +       ret = qcom_cc_probe(pdev, match->data);
> +       if (ret)
> +               return ret;
> +
> +       return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);

How about calling of_syscon_register() instead? That would give us a
handle to a regmap that can be consumed in e.g. the thermal driver.

I think this use case is exactly why that was introduced.

Regards,
Bjorn

Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Srinivas Kandagatla]

On 30/01/15 16:57, Bjorn Andersson wrote:
> On Fri, Jan 30, 2015 at 2:17 AM, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>> This patch adds support to add child devices to gcc as some of the
>> registers mapped by gcc are used by drivers like thermal sensors.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>>   drivers/clk/qcom/gcc-msm8960.c | 10 +++++++++-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
>> index 0cd3e26..3ba77c5 100644
>> --- a/drivers/clk/qcom/gcc-msm8960.c
>> +++ b/drivers/clk/qcom/gcc-msm8960.c
>> @@ -15,6 +15,7 @@
>>   #include <linux/bitops.h>
>>   #include <linux/err.h>
>>   #include <linux/platform_device.h>
>> +#include <linux/of_platform.h>
>>   #include <linux/module.h>
>>   #include <linux/of.h>
>>   #include <linux/of_device.h>
>> @@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct platform_device *pdev)
>>          struct clk *clk;
>>          struct device *dev = &pdev->dev;
>>          const struct of_device_id *match;
>> +       int ret;
>>
>>          match = of_match_device(gcc_msm8960_match_table, &pdev->dev);
>>          if (!match)
>> @@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct platform_device *pdev)
>>          if (IS_ERR(clk))
>>                  return PTR_ERR(clk);
>>
>> -       return qcom_cc_probe(pdev, match->data);
>> +       ret = qcom_cc_probe(pdev, match->data);
>> +       if (ret)
>> +               return ret;
>> +
>> +       return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>
> How about calling of_syscon_register() instead? That would give us a
> handle to a regmap that can be consumed in e.g. the thermal driver.

Two things:
- Are you sure, this looks like of_syscon_register() is a static function
- gcc node would be required to add "syscon" compatible

Unless am missing some patches, Am not sure if going via syscon is right 
thing here?

Stephen Any comments?



--srini

>
> I think this use case is exactly why that was introduced.
>
> Regards,
> Bjorn
>

Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Stephen Boyd]

On 01/30/15 10:06, Srinivas Kandagatla wrote:
>
>
> On 30/01/15 16:57, Bjorn Andersson wrote:
>> On Fri, Jan 30, 2015 at 2:17 AM, Srinivas Kandagatla
>> <srinivas.kandagatla@linaro.org> wrote:
>>> This patch adds support to add child devices to gcc as some of the
>>> registers mapped by gcc are used by drivers like thermal sensors.
>>>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>> ---
>>>   drivers/clk/qcom/gcc-msm8960.c | 10 +++++++++-
>>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/qcom/gcc-msm8960.c
>>> b/drivers/clk/qcom/gcc-msm8960.c
>>> index 0cd3e26..3ba77c5 100644
>>> --- a/drivers/clk/qcom/gcc-msm8960.c
>>> +++ b/drivers/clk/qcom/gcc-msm8960.c
>>> @@ -15,6 +15,7 @@
>>>   #include <linux/bitops.h>
>>>   #include <linux/err.h>
>>>   #include <linux/platform_device.h>
>>> +#include <linux/of_platform.h>
>>>   #include <linux/module.h>
>>>   #include <linux/of.h>
>>>   #include <linux/of_device.h>
>>> @@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct
>>> platform_device *pdev)
>>>          struct clk *clk;
>>>          struct device *dev = &pdev->dev;
>>>          const struct of_device_id *match;
>>> +       int ret;
>>>
>>>          match = of_match_device(gcc_msm8960_match_table, &pdev->dev);
>>>          if (!match)
>>> @@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct
>>> platform_device *pdev)
>>>          if (IS_ERR(clk))
>>>                  return PTR_ERR(clk);
>>>
>>> -       return qcom_cc_probe(pdev, match->data);
>>> +       ret = qcom_cc_probe(pdev, match->data);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       return of_platform_populate(pdev->dev.of_node, NULL, NULL,
>>> &pdev->dev);
>>
>> How about calling of_syscon_register() instead? That would give us a
>> handle to a regmap that can be consumed in e.g. the thermal driver.
>
> Two things:
> - Are you sure, this looks like of_syscon_register() is a static function
> - gcc node would be required to add "syscon" compatible
>
> Unless am missing some patches, Am not sure if going via syscon is
> right thing here?
>
> Stephen Any comments?

I don't understand any of this. We should be making a specific tsens
device directly in the gcc driver probe and not doing any sort of
of_platform_populate(). This is what I had, but it probably could be
done better so that we can assign the struct device's of_node pointer
before registering on the platform bus.

        platform_device_register_data(&pdev->dev, "tsens8960-tm", -1,
                        &pdev->dev.of_node, sizeof(&pdev->dev.of_node));

Then if we need to add any properties like #sensor-cells or coefficients
the tsens driver can use the same of_node that gcc is using.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Bjorn Andersson]

On Fri, Jan 30, 2015 at 1:16 PM, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> On 01/30/15 10:06, Srinivas Kandagatla wrote:
[..]
>> Stephen Any comments?
>
> I don't understand any of this. We should be making a specific tsens
> device directly in the gcc driver probe and not doing any sort of
> of_platform_populate(). This is what I had, but it probably could be
> done better so that we can assign the struct device's of_node pointer
> before registering on the platform bus.
>
>         platform_device_register_data(&pdev->dev, "tsens8960-tm", -1,
>                         &pdev->dev.of_node, sizeof(&pdev->dev.of_node));
>
> Then if we need to add any properties like #sensor-cells or coefficients
> the tsens driver can use the same of_node that gcc is using.
>

That makes sense and the dt will describe the hardware nicely, but how
do you get access to the register space from the tsens driver?

Will dev_get_regmap(pdev->dev.parent, NULL); find the mmio regmap of
gcc perhaps?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Bjorn Andersson]

On Fri, Jan 30, 2015 at 1:16 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 01/30/15 10:06, Srinivas Kandagatla wrote:
[..]
>> Stephen Any comments?
>
> I don't understand any of this. We should be making a specific tsens
> device directly in the gcc driver probe and not doing any sort of
> of_platform_populate(). This is what I had, but it probably could be
> done better so that we can assign the struct device's of_node pointer
> before registering on the platform bus.
>
>         platform_device_register_data(&pdev->dev, "tsens8960-tm", -1,
>                         &pdev->dev.of_node, sizeof(&pdev->dev.of_node));
>
> Then if we need to add any properties like #sensor-cells or coefficients
> the tsens driver can use the same of_node that gcc is using.
>

That makes sense and the dt will describe the hardware nicely, but how
do you get access to the register space from the tsens driver?

Will dev_get_regmap(pdev->dev.parent, NULL); find the mmio regmap of
gcc perhaps?

Regards,
Bjorn

Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Stephen Boyd]

On 01/30/15 14:00, Bjorn Andersson wrote:
> On Fri, Jan 30, 2015 at 1:16 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> On 01/30/15 10:06, Srinivas Kandagatla wrote:
> [..]
>>> Stephen Any comments?
>> I don't understand any of this. We should be making a specific tsens
>> device directly in the gcc driver probe and not doing any sort of
>> of_platform_populate(). This is what I had, but it probably could be
>> done better so that we can assign the struct device's of_node pointer
>> before registering on the platform bus.
>>
>>         platform_device_register_data(&pdev->dev, "tsens8960-tm", -1,
>>                         &pdev->dev.of_node, sizeof(&pdev->dev.of_node));
>>
>> Then if we need to add any properties like #sensor-cells or coefficients
>> the tsens driver can use the same of_node that gcc is using.
>>
> That makes sense and the dt will describe the hardware nicely, but how
> do you get access to the register space from the tsens driver?
>
> Will dev_get_regmap(pdev->dev.parent, NULL); find the mmio regmap of
> gcc perhaps?
>

Yes that's the plan. We'll have to do slightly different stuff for 8974
where tsens is split out from gcc into its own space. That should still
be easy enough though by checking the of_node against some compatible
string.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.

[Srinivas Kandagatla]

On 30/01/15 21:16, Stephen Boyd wrote:
> On 01/30/15 10:06, Srinivas Kandagatla wrote:
>>
>>
>> On 30/01/15 16:57, Bjorn Andersson wrote:
>>> On Fri, Jan 30, 2015 at 2:17 AM, Srinivas Kandagatla
>>> <srinivas.kandagatla@linaro.org> wrote:
>>>> This patch adds support to add child devices to gcc as some of the
>>>> registers mapped by gcc are used by drivers like thermal sensors.
>>>>
>>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>> ---
>>>>    drivers/clk/qcom/gcc-msm8960.c | 10 +++++++++-
>>>>    1 file changed, 9 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/qcom/gcc-msm8960.c
>>>> b/drivers/clk/qcom/gcc-msm8960.c
>>>> index 0cd3e26..3ba77c5 100644
>>>> --- a/drivers/clk/qcom/gcc-msm8960.c
>>>> +++ b/drivers/clk/qcom/gcc-msm8960.c
>>>> @@ -15,6 +15,7 @@
>>>>    #include <linux/bitops.h>
>>>>    #include <linux/err.h>
>>>>    #include <linux/platform_device.h>
>>>> +#include <linux/of_platform.h>
>>>>    #include <linux/module.h>
>>>>    #include <linux/of.h>
>>>>    #include <linux/of_device.h>
>>>> @@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct
>>>> platform_device *pdev)
>>>>           struct clk *clk;
>>>>           struct device *dev = &pdev->dev;
>>>>           const struct of_device_id *match;
>>>> +       int ret;
>>>>
>>>>           match = of_match_device(gcc_msm8960_match_table, &pdev->dev);
>>>>           if (!match)
>>>> @@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct
>>>> platform_device *pdev)
>>>>           if (IS_ERR(clk))
>>>>                   return PTR_ERR(clk);
>>>>
>>>> -       return qcom_cc_probe(pdev, match->data);
>>>> +       ret = qcom_cc_probe(pdev, match->data);
>>>> +       if (ret)
>>>> +               return ret;
>>>> +
>>>> +       return of_platform_populate(pdev->dev.of_node, NULL, NULL,
>>>> &pdev->dev);
>>>
>>> How about calling of_syscon_register() instead? That would give us a
>>> handle to a regmap that can be consumed in e.g. the thermal driver.
>>
>> Two things:
>> - Are you sure, this looks like of_syscon_register() is a static function
>> - gcc node would be required to add "syscon" compatible
>>
>> Unless am missing some patches, Am not sure if going via syscon is
>> right thing here?
>>
>> Stephen Any comments?
>
> I don't understand any of this. We should be making a specific tsens
> device directly in the gcc driver probe and not doing any sort of
> of_platform_populate(). This is what I had, but it probably could be
> done better so that we can assign the struct device's of_node pointer
> before registering on the platform bus.
>
>          platform_device_register_data(&pdev->dev, "tsens8960-tm", -1,
>                          &pdev->dev.of_node, sizeof(&pdev->dev.of_node));
>
Yes this would work too, What are the advantages of doing this way over 
the other? Except the fact that gcc and tsens do not have parent child 
relation in hw p.o.v .

If I get all this correct, we do not want to add a parent child 
hierarchy in DT, but we are Ok doing that inside the gcc driver, that 
seem not correct.

TBH, All this looks bit fiddly, for below reasons
- we re going to have a consolidated bindings for two different drivers 
gcc and tsens.
- Passing of_node as data to other drivers.

On the other hand can't we move a level up and make the common resource 
a syscon node and let both gcc and tsens drivers access it?
Which I think tsens originally attempted doing :-)

??

--srini



> Then if we need to add any properties like #sensor-cells or coefficients
> the tsens driver can use the same of_node that gcc is using.
>