From: Vinod Koul <vkoul@kernel.org>
To: Stephen Boyd <sboyd@kernel.org>
Cc: linux-arm-msm@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Vivek Aknurwar <viveka@codeaurora.org>,
Andy Gross <agross@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Rob Herring <robh+dt@kernel.org>,
Taniya Das <tdas@codeaurora.org>,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Jeevan Shriram <jshriram@codeaurora.org>
Subject: Re: [PATCH v2 4/5] clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL
Date: Fri, 11 Dec 2020 10:32:57 +0530 [thread overview]
Message-ID: <20201211050257.GR8403@vkoul-mobl> (raw)
In-Reply-To: <160763259636.1580929.12912274485007017282@swboyd.mtv.corp.google.com>
On 10-12-20, 12:36, Stephen Boyd wrote:
> Quoting Vinod Koul (2020-12-07 22:47:01)
> > diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
> > index 564431130a76..6a399663d564 100644
> > --- a/drivers/clk/qcom/clk-alpha-pll.c
> > +++ b/drivers/clk/qcom/clk-alpha-pll.c
> > @@ -146,6 +146,12 @@ EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
> > /* LUCID PLL specific settings and offsets */
> > #define LUCID_PCAL_DONE BIT(27)
> >
> > +/* LUCID 5LPE PLL specific settings and offsets */
> > +#define LUCID_5LPE_PCAL_DONE BIT(11)
> > +#define LUCID_5LPE_ENABLE_VOTE_RUN BIT(21)
> > +#define LUCID_5LPE_PLL_LATCH_INPUT BIT(14)
> > +#define LUCID_5LPE_ALPHA_PLL_ACK_LATCH BIT(13)
>
> Sort these by bit or define name?
Okay will sort by bit
>
> > +
> > #define pll_alpha_width(p) \
> > ((PLL_ALPHA_VAL_U(p) - PLL_ALPHA_VAL(p) == 4) ? \
> > ALPHA_REG_BITWIDTH : ALPHA_REG_16BIT_WIDTH)
> > @@ -1561,3 +1567,220 @@ const struct clk_ops clk_alpha_pll_postdiv_lucid_ops = {
> > .set_rate = clk_alpha_pll_postdiv_fabia_set_rate,
> > };
> > EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_lucid_ops);
> > +
> > +static int alpha_pll_lucid_5lpe_enable(struct clk_hw *hw)
> > +{
> > + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), &val);
> > + if (ret)
> > + return ret;
> > +
> > + /* If in FSM mode, just vote for it */
> > + if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
> > + ret = clk_enable_regmap(hw);
> > + if (ret)
> > + return ret;
> > + return wait_for_pll_enable_lock(pll);
> > + }
> > +
> > + /* Check if PLL is already enabled */
>
> Yeah that's obvious, but then what?
then dont proceed :) will update
> > + ret = trion_pll_is_enabled(pll, pll->clkr.regmap);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
> > + if (ret)
> > + return ret;
> > +
> > + /* Set operation mode to RUN */
>
> This comment is worthless.
Will drop
>
> > + regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_RUN);
> > +
> > + ret = wait_for_pll_enable_lock(pll);
> > + if (ret)
> > + return ret;
> > +
> > + /* Enable the PLL outputs */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll), PLL_OUT_MASK, PLL_OUT_MASK);
> > + if (ret)
> > + return ret;
> > +
> > + /* Enable the global PLL outputs */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_OUTCTRL, PLL_OUTCTRL);
> > + if (ret)
> > + return ret;
> > +
> > + /* Ensure that the write above goes through before returning. */
> > + mb();
>
> Regmap has a memory barrier in writel. Drop this.
yes
>
> > + return ret;
> > +}
> > +
> > +static void alpha_pll_lucid_5lpe_disable(struct clk_hw *hw)
> > +{
> > + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), &val);
> > + if (ret)
> > + return;
> > +
> > + /* If in FSM mode, just unvote it */
> > + if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
> > + clk_disable_regmap(hw);
> > + return;
> > + }
> > +
> > + /* Disable the global PLL output */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_OUTCTRL, 0);
> > + if (ret)
> > + return;
> > +
> > + /* Disable the PLL outputs */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll), PLL_OUT_MASK, 0);
> > + if (ret)
> > + return;
> > +
> > + /* Place the PLL mode in STANDBY */
> > + regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_STANDBY);
> > +}
> > +
> > +/*
> > + * The Lucid 5LPE PLL requires a power-on self-calibration which happens
> > + * when the PLL comes out of reset. Calibrate in case it is not completed.
> > + */
> > +static int alpha_pll_lucid_5lpe_prepare(struct clk_hw *hw)
> > +{
> > + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > + struct clk_hw *p;
> > + u32 regval;
>
> Can you use u32 val? And also include a patch to replace the couple
> times where there is 'regval' in this file. The former is shorter and
> used far more in qcom clk code.
Will do
>
> > + int ret;
> > +
> > + /* Return early if calibration is not needed. */
> > + regmap_read(pll->clkr.regmap, PLL_MODE(pll), ®val);
> > + if (regval & LUCID_5LPE_PCAL_DONE)
> > + return 0;
> > +
> > + p = clk_hw_get_parent(hw);
> > + if (!p)
> > + return -EINVAL;
> > +
> > + ret = alpha_pll_lucid_5lpe_enable(hw);
> > + if (ret)
> > + return ret;
> > +
> > + alpha_pll_lucid_5lpe_disable(hw);
> > +
> > + return 0;
> > +}
> > +
> > +static int alpha_pll_lucid_5lpe_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;
> > + u64 a;
> > + int ret;
> > +
> > + rrate = alpha_pll_round_rate(rate, prate, &l, &a, ALPHA_REG_16BIT_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) {
> > + pr_err("Call set rate on the PLL with rounded rates!\n");
> > + return -EINVAL;
> > + }
>
> Can we use alpha_pll_check_rate_margin()?
Ah a shiny new helper, looking at it yes we should
>
> > +
> > + 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),
> > + LUCID_5LPE_PLL_LATCH_INPUT, LUCID_5LPE_PLL_LATCH_INPUT);
> > + if (ret)
> > + return ret;
> > +
> > + /* Wait for 2 reference cycles before checking the ACK bit. */
> > + udelay(1);
> > + regmap_read(pll->clkr.regmap, PLL_MODE(pll), ®val);
> > + if (!(regval & LUCID_5LPE_ALPHA_PLL_ACK_LATCH)) {
> > + pr_err("Lucid 5LPE PLL latch failed. Output may be unstable!\n");
> > + return -EINVAL;
> > + }
> > +
> > + /* Return the latch input to 0 */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), LUCID_5LPE_PLL_LATCH_INPUT, 0);
> > + if (ret)
> > + return ret;
> > +
> > + if (clk_hw_is_enabled(hw)) {
> > + ret = wait_for_pll_enable_lock(pll);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + /* Wait for PLL output to stabilize */
> > + udelay(100);
> > + return 0;
> > +}
> > +
> > +static int clk_lucid_5lpe_pll_postdiv_set_rate(struct clk_hw *hw, unsigned long rate,
> > + unsigned long parent_rate)
> > +{
> > + struct clk_alpha_pll_postdiv *pll = to_clk_alpha_pll_postdiv(hw);
> > + int i, val = 0, div, ret;
> > +
> > + /*
> > + * If the PLL is in FSM mode, then treat set_rate callback as a
> > + * no-operation.
> > + */
> > + ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), &val);
> > + if (ret)
> > + return ret;
> > +
> > + if (val & LUCID_5LPE_ENABLE_VOTE_RUN)
> > + return 0;
> > +
> > + if (!pll->post_div_table) {
> > + pr_err("Missing the post_div_table for the PLL\n");
>
> Can this be rolled into the loop below?
Yep
> > + return -EINVAL;
> > + }
> > +
> > + div = DIV_ROUND_UP_ULL((u64)parent_rate, rate);
> > + for (i = 0; i < pll->num_post_div; i++) {
>
> So that this finds nothing.
>
> > + if (pll->post_div_table[i].div == div) {
> > + val = pll->post_div_table[i].val;
> > + break;
> > + }
> > + }
>
> and then if val == -1 we return -EINVAL?
Correct, will update
> > +
> > + return regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
> > + (BIT(pll->width) - 1) << pll->post_div_shift,
>
> Use GENMASK?
Looks like this can be:
GENMASK(pll->width + pll->post_div_shift - 1, pll->post_div_shift)
Not sure which one you like :)
--
~Vinod
next prev parent reply other threads:[~2020-12-11 5:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-08 6:46 [PATCH v2 0/5] Add clock drivers for SM8350 Vinod Koul
2020-12-08 6:46 ` [PATCH v2 1/5] dt-bindings: clock: Add RPMHCC bindings " Vinod Koul
2020-12-10 3:59 ` Rob Herring
2020-12-10 20:44 ` Stephen Boyd
2020-12-08 6:46 ` [PATCH v2 2/5] clk: qcom: rpmh: add support for SM8350 rpmh clocks Vinod Koul
2020-12-10 20:48 ` Stephen Boyd
2020-12-08 6:47 ` [PATCH v2 3/5] dt-bindings: clock: Add SM8350 GCC clock bindings Vinod Koul
2020-12-10 4:01 ` Rob Herring
2020-12-10 6:11 ` Vinod Koul
2020-12-10 20:31 ` Stephen Boyd
2020-12-11 4:29 ` Vinod Koul
2020-12-08 6:47 ` [PATCH v2 4/5] clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL Vinod Koul
2020-12-10 20:36 ` Stephen Boyd
2020-12-11 5:02 ` Vinod Koul [this message]
2020-12-11 7:09 ` Stephen Boyd
2020-12-08 6:47 ` [PATCH v2 5/5] clk: qcom: gcc: Add clock driver for SM8350 Vinod Koul
2020-12-10 20:43 ` Stephen Boyd
2020-12-11 5:43 ` Vinod Koul
2020-12-11 7:10 ` Stephen Boyd
2020-12-13 8:30 ` Taniya Das
2020-12-14 4:40 ` 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=20201211050257.GR8403@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-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=tdas@codeaurora.org \
--cc=viveka@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).