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), ®val); > > + 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), ®val); > > + 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), ®val); > > + 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), ®val); > > + 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
next prev parent 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: linkBe 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.