All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <t.figa@samsung.com>
To: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Cc: naveenkrishna.ch@gmail.com, linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, cpgs@samsung.com,
	Mike Turquette <mturquette@linaro.org>,
	Thomas Abraham <thomas.ab@samsung.com>
Subject: Re: [PATCH 01/14] clk: samsung: add support for 145xx and 1460x PLLs
Date: Wed, 27 Aug 2014 14:10:13 +0200	[thread overview]
Message-ID: <53FDCAA5.1080302@samsung.com> (raw)
In-Reply-To: <1409132889-2080-1-git-send-email-ch.naveen@samsung.com>

On 27.08.2014 11:48, Naveen Krishna Chatradhi wrote:
> By registers bits and offsets the 145xx PLL is similar to
> pll_type "pll_35xx". Also, 1460x PLL is similar to pll_type
> "pll_46xx".
> 
> Hence, reusing the functions defined for pll_35xx and pll_46xx
> to support 145xx and 1460x PLLs respectively.

[snip]

> @@ -139,6 +140,7 @@ static const struct clk_ops samsung_pll3000_clk_ops = {
>  #define PLL35XX_PDIV_SHIFT      (8)
>  #define PLL35XX_SDIV_SHIFT      (0)
>  #define PLL35XX_LOCK_STAT_SHIFT	(29)
> +#define PLL145XX_ENABLE		BIT(31)

The same bit is also present in PLL35XX.

>  
>  static unsigned long samsung_pll35xx_recalc_rate(struct clk_hw *hw,
>  				unsigned long parent_rate)
> @@ -186,6 +188,10 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw, unsigned long drate,
>  
>  	tmp = __raw_readl(pll->con_reg);
>  
> +	/* Enable PLL */
> +	if (pll->type == (pll_1450x || pll_1451x || pll_1452x))
> +		tmp |= PLL145XX_ENABLE;

I believe that the need to enable the PLL is not really specific to
pll_145xx. Any PLL which is initially disabled, should be enabled before
trying to wait until it stabilizes.

> +
>  	if (!(samsung_pll35xx_mp_change(rate, tmp))) {
>  		/* If only s change, change just s value only*/
>  		tmp &= ~(PLL35XX_SDIV_MASK << PLL35XX_SDIV_SHIFT);
> @@ -196,8 +202,12 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw, unsigned long drate,
>  	}
>  
>  	/* Set PLL lock time. */
> -	__raw_writel(rate->pdiv * PLL35XX_LOCK_FACTOR,
> -			pll->lock_reg);
> +	if (pll->type == (pll_1450x || pll_1451x || pll_1452x))
> +		__raw_writel(rate->pdiv * PLL145XX_LOCK_FACTOR,
> +				pll->lock_reg);

If we already have lock_reg in pll, then maybe lock_factor could be
added there too and this code simply parametrized?

> +	else
> +		__raw_writel(rate->pdiv * PLL35XX_LOCK_FACTOR,
> +				pll->lock_reg);
>  
>  	/* Change PLL PMS values */
>  	tmp &= ~((PLL35XX_MDIV_MASK << PLL35XX_MDIV_SHIFT) |
> @@ -356,7 +366,6 @@ static const struct clk_ops samsung_pll36xx_clk_min_ops = {
>  
>  #define PLL45XX_ENABLE		BIT(31)
>  #define PLL45XX_LOCKED		BIT(29)
> -

Stray change?

>  static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
>  				unsigned long parent_rate)
>  {

[snip]

> @@ -573,14 +588,23 @@ static int samsung_pll46xx_set_rate(struct clk_hw *hw, unsigned long drate,
>  		lock = 0xffff;
>  
>  	/* Set PLL PMS and VSEL values. */
> -	con0 &= ~((PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT) |
> +	if (pll->type == pll_1460x) {
> +		con0 &= ~((PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT) |

Shouldn't PLL1460X_MDIV_MASK be used here instead?

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: t.figa@samsung.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/14] clk: samsung: add support for 145xx and 1460x PLLs
Date: Wed, 27 Aug 2014 14:10:13 +0200	[thread overview]
Message-ID: <53FDCAA5.1080302@samsung.com> (raw)
In-Reply-To: <1409132889-2080-1-git-send-email-ch.naveen@samsung.com>

On 27.08.2014 11:48, Naveen Krishna Chatradhi wrote:
> By registers bits and offsets the 145xx PLL is similar to
> pll_type "pll_35xx". Also, 1460x PLL is similar to pll_type
> "pll_46xx".
> 
> Hence, reusing the functions defined for pll_35xx and pll_46xx
> to support 145xx and 1460x PLLs respectively.

[snip]

> @@ -139,6 +140,7 @@ static const struct clk_ops samsung_pll3000_clk_ops = {
>  #define PLL35XX_PDIV_SHIFT      (8)
>  #define PLL35XX_SDIV_SHIFT      (0)
>  #define PLL35XX_LOCK_STAT_SHIFT	(29)
> +#define PLL145XX_ENABLE		BIT(31)

The same bit is also present in PLL35XX.

>  
>  static unsigned long samsung_pll35xx_recalc_rate(struct clk_hw *hw,
>  				unsigned long parent_rate)
> @@ -186,6 +188,10 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw, unsigned long drate,
>  
>  	tmp = __raw_readl(pll->con_reg);
>  
> +	/* Enable PLL */
> +	if (pll->type == (pll_1450x || pll_1451x || pll_1452x))
> +		tmp |= PLL145XX_ENABLE;

I believe that the need to enable the PLL is not really specific to
pll_145xx. Any PLL which is initially disabled, should be enabled before
trying to wait until it stabilizes.

> +
>  	if (!(samsung_pll35xx_mp_change(rate, tmp))) {
>  		/* If only s change, change just s value only*/
>  		tmp &= ~(PLL35XX_SDIV_MASK << PLL35XX_SDIV_SHIFT);
> @@ -196,8 +202,12 @@ static int samsung_pll35xx_set_rate(struct clk_hw *hw, unsigned long drate,
>  	}
>  
>  	/* Set PLL lock time. */
> -	__raw_writel(rate->pdiv * PLL35XX_LOCK_FACTOR,
> -			pll->lock_reg);
> +	if (pll->type == (pll_1450x || pll_1451x || pll_1452x))
> +		__raw_writel(rate->pdiv * PLL145XX_LOCK_FACTOR,
> +				pll->lock_reg);

If we already have lock_reg in pll, then maybe lock_factor could be
added there too and this code simply parametrized?

> +	else
> +		__raw_writel(rate->pdiv * PLL35XX_LOCK_FACTOR,
> +				pll->lock_reg);
>  
>  	/* Change PLL PMS values */
>  	tmp &= ~((PLL35XX_MDIV_MASK << PLL35XX_MDIV_SHIFT) |
> @@ -356,7 +366,6 @@ static const struct clk_ops samsung_pll36xx_clk_min_ops = {
>  
>  #define PLL45XX_ENABLE		BIT(31)
>  #define PLL45XX_LOCKED		BIT(29)
> -

Stray change?

>  static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
>  				unsigned long parent_rate)
>  {

[snip]

> @@ -573,14 +588,23 @@ static int samsung_pll46xx_set_rate(struct clk_hw *hw, unsigned long drate,
>  		lock = 0xffff;
>  
>  	/* Set PLL PMS and VSEL values. */
> -	con0 &= ~((PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT) |
> +	if (pll->type == pll_1460x) {
> +		con0 &= ~((PLL46XX_MDIV_MASK << PLL46XX_MDIV_SHIFT) |

Shouldn't PLL1460X_MDIV_MASK be used here instead?

Best regards,
Tomasz

  parent reply	other threads:[~2014-08-27 12:10 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27  9:48 [PATCH 01/14] clk: samsung: add support for 145xx and 1460x PLLs Naveen Krishna Chatradhi
2014-08-27  9:48 ` Naveen Krishna Chatradhi
2014-08-27  9:48 ` [PATCH 02/14] clk: samsung: Factor out the common code to clk.c Naveen Krishna Chatradhi
2014-08-27  9:48   ` Naveen Krishna Chatradhi
2014-08-27 10:15   ` Naveen Krishna Ch
2014-08-27 10:15     ` Naveen Krishna Ch
2014-08-27  9:48 ` [PATCH 03/14] clk: samsung: Add fixed_factor_clocks field to struct exynos_cmu_info Naveen Krishna Chatradhi
2014-08-27  9:48   ` Naveen Krishna Chatradhi
2014-08-27  9:48 ` [PATCH 04/14] clk: samsung: Add clock description for basic CMU blocks Naveen Krishna Chatradhi
2014-08-27  9:48   ` Naveen Krishna Chatradhi
2014-08-27 12:35   ` Tomasz Figa
2014-08-27 12:35     ` Tomasz Figa
2014-09-03  7:40     ` Naveen Krishna Ch
2014-09-03  7:40       ` Naveen Krishna Ch
2014-08-27  9:48 ` [PATCH 05/14] pinctrl: exynos: Add driver data for Exynos7 Naveen Krishna Chatradhi
2014-08-27  9:48   ` Naveen Krishna Chatradhi
2014-09-02 12:38   ` Linus Walleij
2014-09-02 12:38     ` Linus Walleij
2014-09-02 12:41     ` Tomasz Figa
2014-09-02 12:41       ` Tomasz Figa
2014-08-27  9:48 ` [PATCH 06/14] pinctrl: samsung: use CONFIG_PINCTRL_SAMSUNG symbol in makefile Naveen Krishna Chatradhi
2014-08-27  9:48   ` Naveen Krishna Chatradhi
2014-08-29 12:37   ` Linus Walleij
2014-08-29 12:37     ` Linus Walleij
2014-09-03  7:41     ` Naveen Krishna Ch
2014-09-03  7:41       ` Naveen Krishna Ch
2014-08-27 12:10 ` Tomasz Figa [this message]
2014-08-27 12:10   ` [PATCH 01/14] clk: samsung: add support for 145xx and 1460x PLLs Tomasz Figa
2014-09-03  7:37   ` Naveen Krishna Ch
2014-09-03  7:37     ` Naveen Krishna Ch

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=53FDCAA5.1080302@samsung.com \
    --to=t.figa@samsung.com \
    --cc=ch.naveen@samsung.com \
    --cc=cpgs@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=naveenkrishna.ch@gmail.com \
    --cc=thomas.ab@samsung.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.