All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Mike Turquette <mturquette@linaro.org>,
	Prashant Gaikwad <pgaikwad@nvidia.com>,
	Mark Zhang <markz@nvidia.com>,
	Thierry Reding <treding@nvidia.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: tegra: use pll_ref as the pll_e parent
Date: Wed, 30 Oct 2013 09:41:41 -0600	[thread overview]
Message-ID: <527128B5.2020101@wwwdotorg.org> (raw)
In-Reply-To: <1383093707-10312-1-git-send-email-pdeschrijver@nvidia.com>

On 10/29/2013 06:41 PM, Peter De Schrijver wrote:
> Use pll_ref instead of pll_re_vco as the pll_e parent on Tegra114 and
> Tegra124. Also add a pll_ref table entry for pll_e for Tegra114.

Why? What benefit does this give, or what bug does this fix?

> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c

>  	val_aux = pll_readl(pll_params->aux_reg, pll);
>  
>  	if (val & PLL_BASE_ENABLE) {
> -		if (!(val_aux & PLLE_AUX_PLLRE_SEL))
> +		if ((val_aux & PLLE_AUX_PLLRE_SEL) || (val_aux & val_aux))

Isn't "|| (val_aux & val_aux)" always true, at least if the value is
non-zero? Either this should be simply "|| val_aux", or one of those two
"val_aux" is the wrong thing.

>  			WARN(1, "pll_e enabled with unsupported parent %s\n",
> -			  (val & PLLE_AUX_PLLP_SEL) ? "pllp_out0" : "pll_ref");
> +			  (val_aux & PLLE_AUX_PLLP_SEL) ? "pllp_out0" :
> +					"pll_re_vco");
>  	} else {
> -		val_aux |= PLLE_AUX_PLLRE_SEL;
> +		val_aux &= ~(PLLE_AUX_PLLRE_SEL | PLLE_AUX_PLLP_SEL);
>  		pll_writel(val, pll_params->aux_reg, pll);
>  	}

> diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c

> @@ -560,6 +560,7 @@ static struct tegra_clk_pll_freq_table pll_e_freq_table[] = {
>  	/* PLLE special case: use cpcon field to store cml divider value */
>  	{336000000, 100000000, 100, 21, 16, 11},
>  	{312000000, 100000000, 200, 26, 24, 13},
> +	{12000000, 100000000, 200,  1,  24, 13},

Presumably this is because pll_ref is the crystal, which runs at 12MHz.
What if it doesn't; Tegra supports a bunch of other crystal rates. Don't
we need entries for all the other potential crystal rates too?

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: tegra: use pll_ref as the pll_e parent
Date: Wed, 30 Oct 2013 09:41:41 -0600	[thread overview]
Message-ID: <527128B5.2020101@wwwdotorg.org> (raw)
In-Reply-To: <1383093707-10312-1-git-send-email-pdeschrijver@nvidia.com>

On 10/29/2013 06:41 PM, Peter De Schrijver wrote:
> Use pll_ref instead of pll_re_vco as the pll_e parent on Tegra114 and
> Tegra124. Also add a pll_ref table entry for pll_e for Tegra114.

Why? What benefit does this give, or what bug does this fix?

> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c

>  	val_aux = pll_readl(pll_params->aux_reg, pll);
>  
>  	if (val & PLL_BASE_ENABLE) {
> -		if (!(val_aux & PLLE_AUX_PLLRE_SEL))
> +		if ((val_aux & PLLE_AUX_PLLRE_SEL) || (val_aux & val_aux))

Isn't "|| (val_aux & val_aux)" always true, at least if the value is
non-zero? Either this should be simply "|| val_aux", or one of those two
"val_aux" is the wrong thing.

>  			WARN(1, "pll_e enabled with unsupported parent %s\n",
> -			  (val & PLLE_AUX_PLLP_SEL) ? "pllp_out0" : "pll_ref");
> +			  (val_aux & PLLE_AUX_PLLP_SEL) ? "pllp_out0" :
> +					"pll_re_vco");
>  	} else {
> -		val_aux |= PLLE_AUX_PLLRE_SEL;
> +		val_aux &= ~(PLLE_AUX_PLLRE_SEL | PLLE_AUX_PLLP_SEL);
>  		pll_writel(val, pll_params->aux_reg, pll);
>  	}

> diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c

> @@ -560,6 +560,7 @@ static struct tegra_clk_pll_freq_table pll_e_freq_table[] = {
>  	/* PLLE special case: use cpcon field to store cml divider value */
>  	{336000000, 100000000, 100, 21, 16, 11},
>  	{312000000, 100000000, 200, 26, 24, 13},
> +	{12000000, 100000000, 200,  1,  24, 13},

Presumably this is because pll_ref is the crystal, which runs at 12MHz.
What if it doesn't; Tegra supports a bunch of other crystal rates. Don't
we need entries for all the other potential crystal rates too?

  reply	other threads:[~2013-10-30 15:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-30  0:41 [PATCH] clk: tegra: use pll_ref as the pll_e parent Peter De Schrijver
2013-10-30  0:41 ` Peter De Schrijver
2013-10-30  0:41 ` Peter De Schrijver
2013-10-30 15:41 ` Stephen Warren [this message]
2013-10-30 15:41   ` Stephen Warren
2013-10-30 15:44   ` Lucas Stach
2013-10-30 15:44     ` Lucas Stach
     [not found]     ` <1383147850.4095.3.camel-WzVe3FnzCwFR6QfukMTsflXZhhPuCNm+@public.gmane.org>
2013-10-30 22:19       ` Peter De Schrijver
2013-10-30 22:19         ` Peter De Schrijver
2013-10-30 22:19         ` Peter De Schrijver
     [not found]   ` <527128B5.2020101-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-30 22:18     ` Peter De Schrijver
2013-10-30 22:18       ` Peter De Schrijver
2013-10-30 22:18       ` Peter De Schrijver
     [not found]       ` <20131030221833.GQ22111-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-10-30 22:50         ` Stephen Warren
2013-10-30 22:50           ` Stephen Warren
2013-10-30 22:50           ` Stephen Warren
     [not found]           ` <52718D1B.6030106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-31 15:41             ` Peter De Schrijver
2013-10-31 15:41               ` Peter De Schrijver
2013-10-31 15:41               ` Peter De Schrijver
2013-10-31 16:41               ` Stephen Warren
2013-10-31 16:41                 ` Stephen Warren
     [not found] ` <1383093707-10312-1-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-22 13:40   ` Peter De Schrijver
2013-11-22 13:40     ` Peter De Schrijver
2013-11-22 13:40     ` Peter De Schrijver
     [not found]     ` <20131122134035.GD26617-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-11-25 12:42       ` Peter De Schrijver
2013-11-25 12:42         ` Peter De Schrijver
2013-11-25 12:42         ` Peter De Schrijver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527128B5.2020101@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=markz@nvidia.com \
    --cc=mturquette@linaro.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=pgaikwad@nvidia.com \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.