All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Michael Turquette <mturquette@baylibre.com>,
	Taniya Das <tdas@codeaurora.org>
Cc: David Brown <david.brown@linaro.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andy Gross <agross@kernel.org>,
	devicetree@vger.kernel.org, robh@kernel.org, robh+dt@kernel.org,
	Taniya Das <tdas@codeaurora.org>
Subject: Re: [PATCH v1 1/7] clk: qcom: clk-alpha-pll: Add support for Fabia PLL calibration
Date: Tue, 05 Nov 2019 16:36:54 -0800	[thread overview]
Message-ID: <20191106003654.BCB312178F@mail.kernel.org> (raw)
In-Reply-To: <1572524473-19344-2-git-send-email-tdas@codeaurora.org>

Quoting Taniya Das (2019-10-31 05:21:07)
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
> index 055318f..8cb77ca 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -1141,15 +1160,11 @@ static int alpha_pll_fabia_set_rate(struct clk_hw *hw, unsigned long rate,
>                                                 unsigned long prate)
>  {
>         struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> -       u32 val, l, alpha_width = pll_alpha_width(pll);
> +       u32 l, alpha_width = pll_alpha_width(pll);
>         u64 a;
>         unsigned long rrate;
>         int ret = 0;
> 
> -       ret = regmap_read(pll->clkr.regmap, PLL_MODE(pll), &val);
> -       if (ret)
> -               return ret;
> -
>         rrate = alpha_pll_round_rate(rate, prate, &l, &a, alpha_width);
> 
>         /*

How is this diff related? Looks like it should be split off into another
patch to remove a useless register read.

> @@ -1167,7 +1182,66 @@ static int alpha_pll_fabia_set_rate(struct clk_hw *hw, unsigned long rate,
>         return __clk_alpha_pll_update_latch(pll);
>  }
> 
> +static int alpha_pll_fabia_prepare(struct clk_hw *hw)
> +{

Why are we doing this in prepare vs. doing it at PLL configuration time?
Does it need to be recalibrated each time the PLL is enabled?

> +       struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> +       const struct pll_vco *vco;
> +       struct clk_hw *parent_hw;
> +       unsigned long cal_freq, rrate;
> +       u32 cal_l, regval, alpha_width = pll_alpha_width(pll);
> +       u64 a;
> +       int ret;
> +
> +       /* Check if calibration needs to be done i.e. PLL is in reset */
> +       ret = regmap_read(pll->clkr.regmap, PLL_MODE(pll), &regval);

Please use 'val' instead of 'regval' as regval almost never appears in
this file already.

> +       if (ret)
> +               return ret;
> +
> +       /* Return early if calibration is not needed. */
> +       if (regval & PLL_RESET_N)
> +               return 0;
> +
> +       vco = alpha_pll_find_vco(pll, clk_hw_get_rate(hw));
> +       if (!vco) {
> +               pr_err("alpha pll: not in a valid vco range\n");
> +               return -EINVAL;
> +       }
> +
> +       cal_freq = DIV_ROUND_CLOSEST((pll->vco_table[0].min_freq +
> +                               pll->vco_table[0].max_freq) * 54, 100);

Do we need to cast the first argument to a u64 to avoid overflow?

> +
> +       parent_hw = clk_hw_get_parent(hw);
> +       if (!parent_hw)
> +               return -EINVAL;
> +
> +       rrate = alpha_pll_round_rate(cal_freq, clk_hw_get_rate(parent_hw),
> +                                       &cal_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 > (cal_freq + FABIA_PLL_RATE_MARGIN) || rrate < cal_freq) {
> +               pr_err("Call set rate on the PLL with rounded rates!\n");

This message is weird. Drivers shouldn't need to call set rate with
rounded rates. What is going on?

> +               return -EINVAL;
> +       }
> +
> +       /* Setup PLL for calibration frequency */
> +       regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), cal_l);
> +
> +       /* Bringup the pll at calibration frequency */

capitalize PLL.

> +       ret = clk_alpha_pll_enable(hw);
> +       if (ret) {
> +               pr_err("alpha pll calibration failed\n");
> +               return ret;
> +       }
> +
> +       clk_alpha_pll_disable(hw);
> +
> +       return 0;
> +}
> +

  reply	other threads:[~2019-11-06  0:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 12:21 [PATCH v1 0/7] Add GPU & Video Clock controller driver for SC7180 Taniya Das
2019-10-31 12:21 ` [PATCH v1 1/7] clk: qcom: clk-alpha-pll: Add support for Fabia PLL calibration Taniya Das
2019-11-06  0:36   ` Stephen Boyd [this message]
2019-11-15  8:11     ` Taniya Das
2019-11-07  4:24   ` Doug Anderson
2019-11-15  8:11     ` Taniya Das
2019-10-31 12:21 ` [PATCH v1 2/7] dt-bindings: clock: Add YAML schemas for the QCOM GPUCC clock bindings Taniya Das
2019-11-06  0:26   ` Stephen Boyd
2019-11-06  3:18     ` Rob Herring
2019-10-31 12:21 ` [PATCH v1 3/7] dt-bindings: clock: Introduce QCOM Graphics " Taniya Das
2019-11-06  3:59   ` Rob Herring
2019-10-31 12:21 ` [PATCH v1 4/7] clk: qcom: Add graphics clock controller driver for SC7180 Taniya Das
2019-11-06  0:30   ` Stephen Boyd
2019-11-15  8:11     ` Taniya Das
2019-11-16  5:50       ` Stephen Boyd
2019-10-31 12:21 ` [PATCH v1 5/7] dt-bindings: clock: Add YAML schemas for the QCOM VIDEOCC clock bindings Taniya Das
2019-11-06  4:00   ` Rob Herring
2019-10-31 12:21 ` [PATCH v1 6/7] dt-bindings: clock: Introduce QCOM Video " Taniya Das
2019-11-06  0:37   ` Stephen Boyd
2019-10-31 12:21 ` [PATCH v1 7/7] clk: qcom: Add video clock controller driver for SC7180 Taniya Das
2019-11-06  0:39   ` Stephen Boyd
2019-11-15  8:11     ` Taniya Das
2019-11-16  5:51       ` Stephen Boyd

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=20191106003654.BCB312178F@mail.kernel.org \
    --to=sboyd@kernel.org \
    --cc=agross@kernel.org \
    --cc=david.brown@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rnayak@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=tdas@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.