All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Stephen Boyd <sboyd@kernel.org>
Cc: agross@kernel.org, bjorn.andersson@linaro.org,
	devicetree@vger.kernel.org, jshriram@codeaurora.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org, mark.rutland@arm.com,
	mturquette@baylibre.com, psodagud@codeaurora.org,
	robh+dt@kernel.org, tdas@codeaurora.org, tsoni@codeaurora.org,
	vnkgutta@codeaurora.org
Subject: Re: [PATCH v2 4/7] clk: qcom: clk-alpha-pll: Add support for controlling Lucid PLLs
Date: Mon, 10 Feb 2020 11:26:38 +0530	[thread overview]
Message-ID: <20200210055638.GT2618@vkoul-mobl> (raw)
In-Reply-To: <20200205193353.2BDCC20720@mail.kernel.org>

On 05-02-20, 11:33, Stephen Boyd wrote:
> Quoting Venkata Narendra Kumar Gutta (2020-01-24 14:32:24)
> > diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
> > index 1b073b2..4258ab0 100644
> > --- a/drivers/clk/qcom/clk-alpha-pll.c
> > +++ b/drivers/clk/qcom/clk-alpha-pll.c
> > @@ -1367,3 +1388,172 @@ static int clk_alpha_pll_postdiv_fabia_set_rate(struct clk_hw *hw,
> >         .set_rate = clk_alpha_pll_postdiv_fabia_set_rate,
> >  };
> >  EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_fabia_ops);
> > +
> > +void clk_lucid_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
> 
> Can we get some kernel documentation for this function?

Okay adding

> > +{
> > +       if (config->l)
> > +               regmap_write(regmap, PLL_L_VAL(pll), config->l);
> > +
> > +       regmap_write(regmap, PLL_CAL_L_VAL(pll), LUCID_PLL_CAL_VAL);
> > +
> > +       if (config->alpha)
> > +               regmap_write(regmap, PLL_ALPHA_VAL(pll), config->alpha);
> > +
> > +       if (config->config_ctl_val)
> > +               regmap_write(regmap, PLL_CONFIG_CTL(pll),
> > +                            config->config_ctl_val);
> > +
> > +       if (config->config_ctl_hi_val)
> > +               regmap_write(regmap, PLL_CONFIG_CTL_U(pll),
> > +                            config->config_ctl_hi_val);
> > +
> > +       if (config->config_ctl_hi1_val)
> > +               regmap_write(regmap, PLL_CONFIG_CTL_U1(pll),
> > +                            config->config_ctl_hi1_val);
> > +
> > +       if (config->user_ctl_val)
> > +               regmap_write(regmap, PLL_USER_CTL(pll),
> > +                            config->user_ctl_val);
> > +
> > +       if (config->user_ctl_hi_val)
> > +               regmap_write(regmap, PLL_USER_CTL_U(pll),
> > +                            config->user_ctl_hi_val);
> > +
> > +       if (config->user_ctl_hi1_val)
> > +               regmap_write(regmap, PLL_USER_CTL_U1(pll),
> > +                            config->user_ctl_hi1_val);
> > +
> > +       if (config->test_ctl_val)
> > +               regmap_write(regmap, PLL_TEST_CTL(pll),
> > +                            config->test_ctl_val);
> > +
> > +       if (config->test_ctl_hi_val)
> > +               regmap_write(regmap, PLL_TEST_CTL_U(pll),
> > +                            config->test_ctl_hi_val);
> > +
> > +       if (config->test_ctl_hi1_val)
> > +               regmap_write(regmap, PLL_TEST_CTL_U1(pll),
> > +                            config->test_ctl_hi1_val);
> > +
> > +       regmap_update_bits(regmap, PLL_MODE(pll), PLL_UPDATE_BYPASS,
> > +                          PLL_UPDATE_BYPASS);
> > +
> > +       /* Disable PLL output */
> > +       regmap_update_bits(regmap, PLL_MODE(pll),  PLL_OUTCTRL, 0);
> > +
> > +       /* Set operation mode to OFF */
> > +       regmap_write(regmap, PLL_OPMODE(pll), PLL_STANDBY);
> > +
> > +       /* PLL should be in OFF mode before continuing */
> > +       wmb();
> 
> How does the write above overtake the write below? This barrier looks
> wrong.

I think you are correct, it doesnt :), so removing this

> > +static int alpha_pll_lucid_prepare(struct clk_hw *hw)
> > +{
> > +       struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > +       u32 regval;
> > +       int ret;
> > +
> > +       /* Return early if calibration is not needed. */
> > +       regmap_read(pll->clkr.regmap, PLL_STATUS(pll), &regval);
> > +       if (regval & LUCID_PCAL_DONE)
> > +               return 0;
> > +
> > +       ret = clk_trion_pll_enable(hw);
> > +       if (ret)
> > +               return ret;
> > +
> > +       clk_trion_pll_disable(hw);
> > +
> > +       return 0;
> 
> Can you write this like:
> 
> 	/* On/off to calibrate */
> 	ret = clk_trion_pll_enable(hw);
> 	if (!ret)
> 		clk_trion_pll_disable(hw);
> 
> 	return ret;

Looks better, updated now.

> > +static int alpha_pll_lucid_set_rate(struct clk_hw *hw, unsigned long rate,
> > +                                   unsigned long prate)
> > +{
> > +       struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > +       unsigned long rrate;
> > +       u32 regval, l, alpha_width = pll_alpha_width(pll);
> > +       u64 a;
> > +       int ret;
> > +
> > +       rrate = alpha_pll_round_rate(rate, prate, &l, &a, alpha_width);
> > +
> > +       /*
> > +        * Due to a limited number of bits for fractional rate programming, the
> > +        * rounded up rate could be marginally higher than the requested rate.
> > +        */
> > +       if (rrate > (rate + PLL_RATE_MARGIN) || rrate < rate) {
> 
> Any chance this can be pushed into the alpha_pll_round_rate() API? It's
> duplicated in this driver.

Yes here and couple of fabia pll functions. Said that I see
alpha_pll_round_rate() is also invoked two places,
alpha_pll_fabia_set_rate() and __clk_alpha_pll_set_rate(), so should we
let these two also be updated, if you are okay with that I will update
this

> > +       regmap_write(pll->clkr.regmap, PLL_L_VAL(pll), l);
> > +       regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a);
> > +
> > +       /* Latch the PLL input */
> > +       ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> > +                                PLL_UPDATE, PLL_UPDATE);
> > +       if (ret)
> > +               return ret;
> > +
> > +       /* Wait for 2 reference cycles before checking the ACK bit. */
> 
> Are reference cycles 2 * 1 / 19.2MHz?

Will check and update on this

> 
> > +       udelay(1);
> > +       regmap_read(pll->clkr.regmap, PLL_MODE(pll), &regval);
> > +       if (!(regval & ALPHA_PLL_ACK_LATCH)) {
> > +               WARN(1, "PLL latch failed. Output may be unstable!\n");
> 
> Do we need a big WARN stack for this? How about pr_warn() instead?

Nope :), will move to a warn print :)

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Stephen Boyd <sboyd@kernel.org>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	tdas@codeaurora.org, jshriram@codeaurora.org,
	linux-arm-msm@vger.kernel.org, mturquette@baylibre.com,
	tsoni@codeaurora.org, vnkgutta@codeaurora.org,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	bjorn.andersson@linaro.org, agross@kernel.org,
	psodagud@codeaurora.org, linux-clk@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/7] clk: qcom: clk-alpha-pll: Add support for controlling Lucid PLLs
Date: Mon, 10 Feb 2020 11:26:38 +0530	[thread overview]
Message-ID: <20200210055638.GT2618@vkoul-mobl> (raw)
In-Reply-To: <20200205193353.2BDCC20720@mail.kernel.org>

On 05-02-20, 11:33, Stephen Boyd wrote:
> Quoting Venkata Narendra Kumar Gutta (2020-01-24 14:32:24)
> > diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
> > index 1b073b2..4258ab0 100644
> > --- a/drivers/clk/qcom/clk-alpha-pll.c
> > +++ b/drivers/clk/qcom/clk-alpha-pll.c
> > @@ -1367,3 +1388,172 @@ static int clk_alpha_pll_postdiv_fabia_set_rate(struct clk_hw *hw,
> >         .set_rate = clk_alpha_pll_postdiv_fabia_set_rate,
> >  };
> >  EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_fabia_ops);
> > +
> > +void clk_lucid_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
> 
> Can we get some kernel documentation for this function?

Okay adding

> > +{
> > +       if (config->l)
> > +               regmap_write(regmap, PLL_L_VAL(pll), config->l);
> > +
> > +       regmap_write(regmap, PLL_CAL_L_VAL(pll), LUCID_PLL_CAL_VAL);
> > +
> > +       if (config->alpha)
> > +               regmap_write(regmap, PLL_ALPHA_VAL(pll), config->alpha);
> > +
> > +       if (config->config_ctl_val)
> > +               regmap_write(regmap, PLL_CONFIG_CTL(pll),
> > +                            config->config_ctl_val);
> > +
> > +       if (config->config_ctl_hi_val)
> > +               regmap_write(regmap, PLL_CONFIG_CTL_U(pll),
> > +                            config->config_ctl_hi_val);
> > +
> > +       if (config->config_ctl_hi1_val)
> > +               regmap_write(regmap, PLL_CONFIG_CTL_U1(pll),
> > +                            config->config_ctl_hi1_val);
> > +
> > +       if (config->user_ctl_val)
> > +               regmap_write(regmap, PLL_USER_CTL(pll),
> > +                            config->user_ctl_val);
> > +
> > +       if (config->user_ctl_hi_val)
> > +               regmap_write(regmap, PLL_USER_CTL_U(pll),
> > +                            config->user_ctl_hi_val);
> > +
> > +       if (config->user_ctl_hi1_val)
> > +               regmap_write(regmap, PLL_USER_CTL_U1(pll),
> > +                            config->user_ctl_hi1_val);
> > +
> > +       if (config->test_ctl_val)
> > +               regmap_write(regmap, PLL_TEST_CTL(pll),
> > +                            config->test_ctl_val);
> > +
> > +       if (config->test_ctl_hi_val)
> > +               regmap_write(regmap, PLL_TEST_CTL_U(pll),
> > +                            config->test_ctl_hi_val);
> > +
> > +       if (config->test_ctl_hi1_val)
> > +               regmap_write(regmap, PLL_TEST_CTL_U1(pll),
> > +                            config->test_ctl_hi1_val);
> > +
> > +       regmap_update_bits(regmap, PLL_MODE(pll), PLL_UPDATE_BYPASS,
> > +                          PLL_UPDATE_BYPASS);
> > +
> > +       /* Disable PLL output */
> > +       regmap_update_bits(regmap, PLL_MODE(pll),  PLL_OUTCTRL, 0);
> > +
> > +       /* Set operation mode to OFF */
> > +       regmap_write(regmap, PLL_OPMODE(pll), PLL_STANDBY);
> > +
> > +       /* PLL should be in OFF mode before continuing */
> > +       wmb();
> 
> How does the write above overtake the write below? This barrier looks
> wrong.

I think you are correct, it doesnt :), so removing this

> > +static int alpha_pll_lucid_prepare(struct clk_hw *hw)
> > +{
> > +       struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > +       u32 regval;
> > +       int ret;
> > +
> > +       /* Return early if calibration is not needed. */
> > +       regmap_read(pll->clkr.regmap, PLL_STATUS(pll), &regval);
> > +       if (regval & LUCID_PCAL_DONE)
> > +               return 0;
> > +
> > +       ret = clk_trion_pll_enable(hw);
> > +       if (ret)
> > +               return ret;
> > +
> > +       clk_trion_pll_disable(hw);
> > +
> > +       return 0;
> 
> Can you write this like:
> 
> 	/* On/off to calibrate */
> 	ret = clk_trion_pll_enable(hw);
> 	if (!ret)
> 		clk_trion_pll_disable(hw);
> 
> 	return ret;

Looks better, updated now.

> > +static int alpha_pll_lucid_set_rate(struct clk_hw *hw, unsigned long rate,
> > +                                   unsigned long prate)
> > +{
> > +       struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > +       unsigned long rrate;
> > +       u32 regval, l, alpha_width = pll_alpha_width(pll);
> > +       u64 a;
> > +       int ret;
> > +
> > +       rrate = alpha_pll_round_rate(rate, prate, &l, &a, alpha_width);
> > +
> > +       /*
> > +        * Due to a limited number of bits for fractional rate programming, the
> > +        * rounded up rate could be marginally higher than the requested rate.
> > +        */
> > +       if (rrate > (rate + PLL_RATE_MARGIN) || rrate < rate) {
> 
> Any chance this can be pushed into the alpha_pll_round_rate() API? It's
> duplicated in this driver.

Yes here and couple of fabia pll functions. Said that I see
alpha_pll_round_rate() is also invoked two places,
alpha_pll_fabia_set_rate() and __clk_alpha_pll_set_rate(), so should we
let these two also be updated, if you are okay with that I will update
this

> > +       regmap_write(pll->clkr.regmap, PLL_L_VAL(pll), l);
> > +       regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a);
> > +
> > +       /* Latch the PLL input */
> > +       ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> > +                                PLL_UPDATE, PLL_UPDATE);
> > +       if (ret)
> > +               return ret;
> > +
> > +       /* Wait for 2 reference cycles before checking the ACK bit. */
> 
> Are reference cycles 2 * 1 / 19.2MHz?

Will check and update on this

> 
> > +       udelay(1);
> > +       regmap_read(pll->clkr.regmap, PLL_MODE(pll), &regval);
> > +       if (!(regval & ALPHA_PLL_ACK_LATCH)) {
> > +               WARN(1, "PLL latch failed. Output may be unstable!\n");
> 
> Do we need a big WARN stack for this? How about pr_warn() instead?

Nope :), will move to a warn print :)

-- 
~Vinod

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-02-10  5:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 22:32 [PATCH v2 0/7] Add device tree and clock drivers for SM8250 SoC Venkata Narendra Kumar Gutta
2020-01-24 22:32 ` Venkata Narendra Kumar Gutta
2020-01-24 22:32 ` [PATCH v2 1/7] dt-bindings: clock: Add RPMHCC bindings for SM8250 Venkata Narendra Kumar Gutta
2020-01-24 22:32   ` Venkata Narendra Kumar Gutta
2020-02-12 23:05   ` Stephen Boyd
2020-02-12 23:05     ` Stephen Boyd
2020-01-24 22:32 ` [PATCH v2 2/7] clk: qcom: rpmh: Add support for RPMH clocks on SM8250 Venkata Narendra Kumar Gutta
2020-01-24 22:32   ` Venkata Narendra Kumar Gutta
2020-02-12 23:05   ` Stephen Boyd
2020-02-12 23:05     ` Stephen Boyd
2020-01-24 22:32 ` [PATCH v2 3/7] clk: qcom: clk-alpha-pll: Refactor and cleanup trion PLL Venkata Narendra Kumar Gutta
2020-01-24 22:32   ` Venkata Narendra Kumar Gutta
2020-02-12 23:09   ` Stephen Boyd
2020-02-12 23:09     ` Stephen Boyd
2020-01-24 22:32 ` [PATCH v2 4/7] clk: qcom: clk-alpha-pll: Add support for controlling Lucid PLLs Venkata Narendra Kumar Gutta
2020-01-24 22:32   ` Venkata Narendra Kumar Gutta
2020-02-05 19:33   ` Stephen Boyd
2020-02-05 19:33     ` Stephen Boyd
2020-02-10  5:56     ` Vinod Koul [this message]
2020-02-10  5:56       ` Vinod Koul
2020-01-24 22:32 ` [PATCH v2 5/7] dt-bindings: clock: Add SM8250 GCC clock bindings Venkata Narendra Kumar Gutta
2020-01-24 22:32   ` Venkata Narendra Kumar Gutta
2020-02-04  7:13   ` Stephen Boyd
2020-02-04  7:13     ` Stephen Boyd
2020-01-24 22:32 ` [PATCH v2 6/7] clk: qcom: gcc: Add global clock controller driver for SM8250 Venkata Narendra Kumar Gutta
2020-02-05 19:40   ` Stephen Boyd
2020-02-05 19:40     ` Stephen Boyd
2020-02-14 13:09     ` Vinod Koul
2020-02-14 13:09       ` Vinod Koul
2020-01-24 22:32 ` [PATCH v2 7/7] arm64: dts: qcom: sm8250: Add sm8250 dts file Venkata Narendra Kumar Gutta
2020-01-24 22:32   ` Venkata Narendra Kumar Gutta
2020-01-24 22:49   ` Bjorn Andersson
2020-01-24 22:49     ` Bjorn Andersson
2020-02-05 19:47   ` Stephen Boyd
2020-02-05 19:47     ` Stephen Boyd
2020-02-14 13:14     ` Vinod Koul
2020-02-14 13:14       ` Vinod Koul

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=20200210055638.GT2618@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jshriram@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=psodagud@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tdas@codeaurora.org \
    --cc=tsoni@codeaurora.org \
    --cc=vnkgutta@codeaurora.org \
    /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.