Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1231661 > unrolled thread

[PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC

Back to article view | Back to linux.kernel

Contents

  [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC Stephen Boyd <sboyd@codeaurora.org> - 2015-09-23 21:10 +0200
    Re: [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC Rajendra Nayak <rnayak@codeaurora.org> - 2015-10-01 10:30 +0200
      Re: [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC Stephen Boyd <sboyd@codeaurora.org> - 2015-10-01 20:00 +0200
        Re: [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC Stephen Boyd <sboyd@codeaurora.org> - 2015-10-01 21:10 +0200
          Re: [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC Rajendra Nayak <rnayak@codeaurora.org> - 2015-10-05 07:10 +0200
            Re: [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC Stephen Boyd <sboyd@codeaurora.org> - 2015-10-05 20:20 +0200

#1231661 — [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC

The oxili_cx GDSC is inside the power domain of the oxili GDSC.
Add the dependency so that the CX domain can properly power up.

Reported-by: Rob Clark <robdclark@gmail.com>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 drivers/clk/qcom/mmcc-msm8974.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
index fe8320dc41db..3613db0a73e3 100644
--- a/drivers/clk/qcom/mmcc-msm8974.c
+++ b/drivers/clk/qcom/mmcc-msm8974.c
@@ -2615,6 +2615,7 @@ MODULE_DEVICE_TABLE(of, mmcc_msm8974_match_table);
 static int mmcc_msm8974_probe(struct platform_device *pdev)
 {
 	struct regmap *regmap;
+	int ret;
 
 	regmap = qcom_cc_map(pdev, &mmcc_msm8974_desc);
 	if (IS_ERR(regmap))
@@ -2623,7 +2624,14 @@ static int mmcc_msm8974_probe(struct platform_device *pdev)
 	clk_pll_configure_sr_hpm_lp(&mmpll1, regmap, &mmpll1_config, true);
 	clk_pll_configure_sr_hpm_lp(&mmpll3, regmap, &mmpll3_config, false);
 
-	return qcom_cc_really_probe(pdev, &mmcc_msm8974_desc, regmap);
+	ret = qcom_cc_really_probe(pdev, &mmcc_msm8974_desc, regmap);
+	if (ret)
+		return ret;
+
+	ret = pm_genpd_add_subdomain(&oxili_gdsc.pd, &oxilicx_gdsc.pd);
+	if (ret)
+		qcom_cc_remove(pdev);
+	return ret;
 }
 
 static int mmcc_msm8974_remove(struct platform_device *pdev)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1237120

On 09/24/2015 12:39 AM, Stephen Boyd wrote:
> The oxili_cx GDSC is inside the power domain of the oxili GDSC.
> Add the dependency so that the CX domain can properly power up.
>
> Reported-by: Rob Clark <robdclark@gmail.com>
> Cc: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>   drivers/clk/qcom/mmcc-msm8974.c | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
> index fe8320dc41db..3613db0a73e3 100644
> --- a/drivers/clk/qcom/mmcc-msm8974.c
> +++ b/drivers/clk/qcom/mmcc-msm8974.c
> @@ -2615,6 +2615,7 @@ MODULE_DEVICE_TABLE(of, mmcc_msm8974_match_table);
>   static int mmcc_msm8974_probe(struct platform_device *pdev)
>   {
>   	struct regmap *regmap;
> +	int ret;
>
>   	regmap = qcom_cc_map(pdev, &mmcc_msm8974_desc);
>   	if (IS_ERR(regmap))
> @@ -2623,7 +2624,14 @@ static int mmcc_msm8974_probe(struct platform_device *pdev)
>   	clk_pll_configure_sr_hpm_lp(&mmpll1, regmap, &mmpll1_config, true);
>   	clk_pll_configure_sr_hpm_lp(&mmpll3, regmap, &mmpll3_config, false);
>
> -	return qcom_cc_really_probe(pdev, &mmcc_msm8974_desc, regmap);
> +	ret = qcom_cc_really_probe(pdev, &mmcc_msm8974_desc, regmap);
> +	if (ret)
> +		return ret;
> +
> +	ret = pm_genpd_add_subdomain(&oxili_gdsc.pd, &oxilicx_gdsc.pd);

We'll need pm_genpd_add_subdomain() to be EXPORT_SYMBOL_GPL'ed so
clk-qcom can be built as a module.

It would also be nicer if this parent/child relationship can
somehow be represented in data (struct gdsc) that gets passed to
the gdsc driver which then sets it up, instead of individual
clock drivers doing it.

> +	if (ret)
> +		qcom_cc_remove(pdev);
> +	return ret;
>   }
>
>   static int mmcc_msm8974_remove(struct platform_device *pdev)
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237601

On 10/01, Rajendra Nayak wrote:
> On 09/24/2015 12:39 AM, Stephen Boyd wrote:
> >The oxili_cx GDSC is inside the power domain of the oxili GDSC.
> >Add the dependency so that the CX domain can properly power up.
> >
> >Reported-by: Rob Clark <robdclark@gmail.com>
> >Cc: Rajendra Nayak <rnayak@codeaurora.org>
> >Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >---
> >  drivers/clk/qcom/mmcc-msm8974.c | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
> >index fe8320dc41db..3613db0a73e3 100644
> >--- a/drivers/clk/qcom/mmcc-msm8974.c
> >+++ b/drivers/clk/qcom/mmcc-msm8974.c
> >@@ -2615,6 +2615,7 @@ MODULE_DEVICE_TABLE(of, mmcc_msm8974_match_table);
> >  static int mmcc_msm8974_probe(struct platform_device *pdev)
> >  {
> >  	struct regmap *regmap;
> >+	int ret;
> >
> >  	regmap = qcom_cc_map(pdev, &mmcc_msm8974_desc);
> >  	if (IS_ERR(regmap))
> >@@ -2623,7 +2624,14 @@ static int mmcc_msm8974_probe(struct platform_device *pdev)
> >  	clk_pll_configure_sr_hpm_lp(&mmpll1, regmap, &mmpll1_config, true);
> >  	clk_pll_configure_sr_hpm_lp(&mmpll3, regmap, &mmpll3_config, false);
> >
> >-	return qcom_cc_really_probe(pdev, &mmcc_msm8974_desc, regmap);
> >+	ret = qcom_cc_really_probe(pdev, &mmcc_msm8974_desc, regmap);
> >+	if (ret)
> >+		return ret;
> >+
> >+	ret = pm_genpd_add_subdomain(&oxili_gdsc.pd, &oxilicx_gdsc.pd);
> 
> We'll need pm_genpd_add_subdomain() to be EXPORT_SYMBOL_GPL'ed so
> clk-qcom can be built as a module.

Good catch! Do we need to call pm_genpd_remove_subdomain() too?

> 
> It would also be nicer if this parent/child relationship can
> somehow be represented in data (struct gdsc) that gets passed to
> the gdsc driver which then sets it up, instead of individual
> clock drivers doing it.

Agreed. I'd rather that we do nothing besides register domains
and then let the core code handle hooking up domains and
subdomains.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237666

On 10/01, Stephen Boyd wrote:
> On 10/01, Rajendra Nayak wrote:
> > On 09/24/2015 12:39 AM, Stephen Boyd wrote:
> > >+
> > >+	ret = pm_genpd_add_subdomain(&oxili_gdsc.pd, &oxilicx_gdsc.pd);
> > 
> > We'll need pm_genpd_add_subdomain() to be EXPORT_SYMBOL_GPL'ed so
> > clk-qcom can be built as a module.
> 
> Good catch! Do we need to call pm_genpd_remove_subdomain() too?

Looks like yes.

> 
> > 
> > It would also be nicer if this parent/child relationship can
> > somehow be represented in data (struct gdsc) that gets passed to
> > the gdsc driver which then sets it up, instead of individual
> > clock drivers doing it.
> 
> Agreed. I'd rather that we do nothing besides register domains
> and then let the core code handle hooking up domains and
> subdomains.

A little closer inspection makes me want to skip this. PM domains
can have multiple "master" domains, and pm_genpd_init() is the
only API that would be able to do the linking. That API is mostly
about initializing things to default values, so it doesn't seem
like a good fit. I'll send a v2 with the remove part and the
exports.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239279

[]...

>>> It would also be nicer if this parent/child relationship can
>>> somehow be represented in data (struct gdsc) that gets passed to
>>> the gdsc driver which then sets it up, instead of individual
>>> clock drivers doing it.
>>
>> Agreed. I'd rather that we do nothing besides register domains
>> and then let the core code handle hooking up domains and
>> subdomains.
> 
> A little closer inspection makes me want to skip this. PM domains
> can have multiple "master" domains, and pm_genpd_init() is the
> only API that would be able to do the linking. That API is mostly
> about initializing things to default values, so it doesn't seem
> like a good fit. I'll send a v2 with the remove part and the
> exports.

What I was suggesting is that the qcom gdsc driver handle this
instead of the qcom clock drivers.
Something like..

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index da9fad8..00edb2d 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -226,6 +226,8 @@ int gdsc_register(struct device *dev, struct gdsc **scs, size_t num,
 		if (ret)
 			return ret;
 		data->domains[i] = &scs[i]->pd;
+		if (scs[i]->parent)
+			pm_genpd_add_subdomain(scs[i]->parent, &scs[i]->pd);
 	}
 
 	return of_genpd_add_provider_onecell(dev->of_node, data);
diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
index 5ded268..bc5791f 100644
--- a/drivers/clk/qcom/gdsc.h
+++ b/drivers/clk/qcom/gdsc.h
@@ -49,6 +49,7 @@ struct gdsc {
 	struct reset_controller_dev	*rcdev;
 	unsigned int			*resets;
 	unsigned int			reset_count;
+	struct generic_pm_domain	*parent;
 };
 
 #ifdef CONFIG_QCOM_GDSC
diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
index fe8320d..51ad8de 100644
--- a/drivers/clk/qcom/mmcc-msm8974.c
+++ b/drivers/clk/qcom/mmcc-msm8974.c
@@ -2400,6 +2400,7 @@ static struct gdsc oxilicx_gdsc = {
 	.pd = {
 		.name = "oxilicx",
 	},
+	.parent = &oxili_gdsc.pd,
 	.pwrsts = PWRSTS_OFF_ON,
 };

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239828

On 10/05, Rajendra Nayak wrote:
> []...
> 
> >>> It would also be nicer if this parent/child relationship can
> >>> somehow be represented in data (struct gdsc) that gets passed to
> >>> the gdsc driver which then sets it up, instead of individual
> >>> clock drivers doing it.
> >>
> >> Agreed. I'd rather that we do nothing besides register domains
> >> and then let the core code handle hooking up domains and
> >> subdomains.
> > 
> > A little closer inspection makes me want to skip this. PM domains
> > can have multiple "master" domains, and pm_genpd_init() is the
> > only API that would be able to do the linking. That API is mostly
> > about initializing things to default values, so it doesn't seem
> > like a good fit. I'll send a v2 with the remove part and the
> > exports.
> 
> What I was suggesting is that the qcom gdsc driver handle this
> instead of the qcom clock drivers.
> Something like..

Ah ok. This patch will still need the gdscs to be in a certain
order though so that we don't add a subdomain on an uninitialized
domain. So I guess some list of pointer pairs to call the
function on could be done in the qcom_cc_desc structure if we
need to do this more than a couple times.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web