[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <abc662f3-8c36-862d-4d50-3628d3a02ee2@marek.ca>
Date: Tue, 18 May 2021 09:06:23 -0400
From: Jonathan Marek <jonathan@...ek.ca>
To: Vinod Koul <vkoul@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, robert.foss@...aro.org,
andrey.konovalov@...aro.org, Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
"open list:COMMON CLK FRAMEWORK" <linux-clk@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] clk: qcom: clk-alpha-pll: add support for zonda pll
On 5/18/21 7:32 AM, Vinod Koul wrote:
> On 13-05-21, 13:52, Jonathan Marek wrote:
...
>> +/* ZONDA PLL specific */
>> +#define ZONDA_PLL_OUT_MASK 0xf
>> +#define ZONDA_STAY_IN_CFA BIT(16)
>> +#define ZONDA_PLL_FREQ_LOCK_DET BIT(29)
>
> This seems similar to ALPHA_PLL_ACK_LATCH..?
>
The bit is the same, and it is also used with wait_for_pll(), but the
meaning seems different (the usage pattern is different).
>> +const struct clk_ops clk_alpha_pll_postdiv_zonda_ops = {
>> + .recalc_rate = clk_alpha_pll_postdiv_fabia_recalc_rate,
>> + .round_rate = clk_alpha_pll_postdiv_fabia_round_rate,
>> + .set_rate = clk_alpha_pll_postdiv_fabia_set_rate,
>> +};
>> +EXPORT_SYMBOL(clk_alpha_pll_postdiv_zonda_ops);
>
> Why add one more ops when we can reuse clk_alpha_pll_postdiv_fabia_ops
> for this?
>
No reason (copied from downstream), will fix.
>> +
>> + /* Set operation mode to OFF */
>> + regmap_write(regmap, PLL_OPMODE(pll), PLL_STANDBY);
>> +
>> + /* PLL should be in OFF mode before continuing */
>> + wmb();
>
> Why a barrier?
>
Again no reason (copied from downstream, but it doesn't make sense to
have this barrier).
>> +static unsigned long
>> +clk_zonda_pll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
>> +{
>> + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
>> + u32 l, frac;
>> +
>> + regmap_read(pll->clkr.regmap, PLL_L_VAL(pll), &l);
>> + regmap_read(pll->clkr.regmap, PLL_ALPHA_VAL(pll), &frac);
>> +
>> + return alpha_pll_calc_rate(parent_rate, l, frac, ALPHA_BITWIDTH);
>> +}
>
> sounds like you could use clk_trion_pll_recalc_rate() instead
>
I had this thought as well, but alpha_width in
clk_trion_pll_recalc()_rate is 16, here ALPHA_BITWIDTH is 32, so I just
copied this from downstream.
I think changing pll_alpha_width() to return the right value for zonda
will work and allow sharing the function, if you think that's a good idea?
Powered by blists - more mailing lists