From: Stephen Boyd <sboyd@kernel.org>
To: Vinod Koul <vkoul@kernel.org>
Cc: linux-arm-msm@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Deepak Katragadda <dkatraga@codeaurora.org>,
Andy Gross <agross@kernel.org>,
David Brown <david.brown@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
linux-clk@vger.kernel.org, Taniya Das <tdas@codeaurora.org>,
Vinod Koul <vkoul@kernel.org>
Subject: Re: [PATCH v3 2/3] clk: qcom: clk-alpha-pll: Add support for Trion PLLs
Date: Thu, 27 Jun 2019 14:50:26 -0700 [thread overview]
Message-ID: <20190627215027.757982063F@mail.kernel.org> (raw)
In-Reply-To: <20190625063140.17106-3-vkoul@kernel.org>
Quoting Vinod Koul (2019-06-24 23:31:39)
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
> index 2c6773188761..30210f5c6726 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -32,6 +32,7 @@
> # define PLL_LOCK_DET BIT(31)
>
> #define PLL_L_VAL(p) ((p)->offset + (p)->regs[PLL_OFF_L_VAL])
> +#define PLL_CAL_L_VAL(p) ((p)->offset + (p)->regs[PLL_OFF_CAL_L_VAL])
> #define PLL_ALPHA_VAL(p) ((p)->offset + (p)->regs[PLL_OFF_ALPHA_VAL])
> #define PLL_ALPHA_VAL_U(p) ((p)->offset + (p)->regs[PLL_OFF_ALPHA_VAL_U])
>
> @@ -44,14 +45,17 @@
> # define PLL_VCO_MASK 0x3
>
> #define PLL_USER_CTL_U(p) ((p)->offset + (p)->regs[PLL_OFF_USER_CTL_U])
> +#define PLL_USER_CTL_U1(p) ((p)->offset + (p)->regs[PLL_OFF_USER_CTL_U1])
>
> #define PLL_CONFIG_CTL(p) ((p)->offset + (p)->regs[PLL_OFF_CONFIG_CTL])
> #define PLL_CONFIG_CTL_U(p) ((p)->offset + (p)->regs[PLL_OFF_CONFIG_CTL_U])
> +#define PLL_CONFIG_CTL_U1(p) ((p)->offset + (p)->regs[PLL_OFF_CONFIG_CTL_U11])
This looks like a typo, U11 vs U1. So I don't think this has been
compile tested....
> #define PLL_TEST_CTL(p) ((p)->offset + (p)->regs[PLL_OFF_TEST_CTL])
> #define PLL_TEST_CTL_U(p) ((p)->offset + (p)->regs[PLL_OFF_TEST_CTL_U])
> #define PLL_STATUS(p) ((p)->offset + (p)->regs[PLL_OFF_STATUS])
> #define PLL_OPMODE(p) ((p)->offset + (p)->regs[PLL_OFF_OPMODE])
> #define PLL_FRAC(p) ((p)->offset + (p)->regs[PLL_OFF_FRAC])
> +#define PLL_CAL_VAL(p) ((p)->offset + (p)->regs[PLL_OFF_CAL_VAL])
>
> const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
> [CLK_ALPHA_PLL_TYPE_DEFAULT] = {
> const struct clk_ops clk_alpha_pll_ops = {
> .enable = clk_alpha_pll_enable,
> .disable = clk_alpha_pll_disable,
> @@ -1053,6 +1210,77 @@ static unsigned long clk_alpha_pll_postdiv_fabia_recalc_rate(struct clk_hw *hw,
[...]
> +
> +static int
> +clk_trion_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);
> + struct regmap *regmap = pll->clkr.regmap;
> + int i, val = 0, div, ret;
> +
> + /*
> + * If the PLL is in FSM mode, then treat the set_rate callback
> + * as a no-operation.
And this is OK? Shouldn't we fail because we can't change to the rate
that's desired?
> + */
> + ret = regmap_read(regmap, PLL_MODE(pll), &val);
> + if (ret)
> + return ret;
> +
> + if (val & PLL_VOTE_FSM_ENA)
> + return 0;
> +
> + div = DIV_ROUND_UP_ULL(parent_rate, rate);
> + for (i = 0; i < pll->num_post_div; i++) {
> + if (pll->post_div_table[i].div == div) {
> + val = pll->post_div_table[i].val;
> + break;
> + }
> + }
> +
> + return regmap_update_bits(regmap, PLL_USER_CTL(pll),
> + PLL_POST_DIV_MASK(pll) << PLL_POST_DIV_SHIFT,
> + val << PLL_POST_DIV_SHIFT);
> +}
next prev parent reply other threads:[~2019-06-27 21:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-25 6:31 [PATCH v3 0/3] clk: qcom: Add support for SM8150 GCC Vinod Koul
2019-06-25 6:31 ` [PATCH v3 1/3] clk: qcom: clk-alpha-pll: Remove post_div_table checks Vinod Koul
2019-06-27 21:37 ` Stephen Boyd
2019-06-29 11:14 ` Vinod Koul
2019-07-16 0:08 ` Bjorn Andersson
2019-07-16 4:08 ` Vinod Koul
2019-06-25 6:31 ` [PATCH v3 2/3] clk: qcom: clk-alpha-pll: Add support for Trion PLLs Vinod Koul
2019-06-27 21:50 ` Stephen Boyd [this message]
2019-06-29 12:28 ` Vinod Koul
[not found] ` <20190625063140.17106-4-vkoul@kernel.org>
2019-06-27 21:31 ` [PATCH v3 3/3] clk: qcom: gcc: Add global clock controller driver for SM8150 Stephen Boyd
2019-06-29 13:51 ` Vinod Koul
2019-07-15 23:01 ` Stephen Boyd
2019-07-16 4:07 ` 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=20190627215027.757982063F@mail.kernel.org \
--to=sboyd@kernel.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=dkatraga@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=tdas@codeaurora.org \
--cc=vkoul@kernel.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).