From: Stephen Boyd <sboyd@kernel.org>
To: 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,
vinod.koul@linaro.org, vnkgutta@codeaurora.org
Subject: Re: [PATCH v2 4/7] clk: qcom: clk-alpha-pll: Add support for controlling Lucid PLLs
Date: Wed, 05 Feb 2020 11:33:52 -0800 [thread overview]
Message-ID: <20200205193353.2BDCC20720@mail.kernel.org> (raw)
In-Reply-To: <1579905147-12142-5-git-send-email-vnkgutta@codeaurora.org>
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?
> + const struct alpha_pll_config *config)
> +{
> + 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.
> +
> + /* Place the PLL in STANDBY mode */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
> +}
> +EXPORT_SYMBOL_GPL(clk_lucid_pll_configure);
> +
> +/*
> + * The Lucid 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_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;
> +}
> +
> +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.
> + pr_err("Call set rate on the PLL with rounded rates!\n");
> + return -EINVAL;
> + }
> +
> + 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?
> + 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?
> + return -EINVAL;
> + }
> +
> + /* Return the latch input to 0 */
> + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> + PLL_UPDATE, 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;
> +}
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: 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,
vinod.koul@linaro.org, vnkgutta@codeaurora.org
Subject: Re: [PATCH v2 4/7] clk: qcom: clk-alpha-pll: Add support for controlling Lucid PLLs
Date: Wed, 05 Feb 2020 11:33:52 -0800 [thread overview]
Message-ID: <20200205193353.2BDCC20720@mail.kernel.org> (raw)
In-Reply-To: <1579905147-12142-5-git-send-email-vnkgutta@codeaurora.org>
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?
> + const struct alpha_pll_config *config)
> +{
> + 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.
> +
> + /* Place the PLL in STANDBY mode */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
> +}
> +EXPORT_SYMBOL_GPL(clk_lucid_pll_configure);
> +
> +/*
> + * The Lucid 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_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;
> +}
> +
> +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.
> + pr_err("Call set rate on the PLL with rounded rates!\n");
> + return -EINVAL;
> + }
> +
> + 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?
> + 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?
> + return -EINVAL;
> + }
> +
> + /* Return the latch input to 0 */
> + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> + PLL_UPDATE, 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;
> +}
_______________________________________________
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-05 19:33 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 [this message]
2020-02-05 19:33 ` Stephen Boyd
2020-02-10 5:56 ` Vinod Koul
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=20200205193353.2BDCC20720@mail.kernel.org \
--to=sboyd@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=tdas@codeaurora.org \
--cc=tsoni@codeaurora.org \
--cc=vinod.koul@linaro.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.