Messages in this thread | | | Date | Thu, 1 Jun 2023 17:43:33 +0300 | Subject | Re: [PATCH V2 3/6] clk: qcom: clk-alpha-pll: Remove explicit CAL_L configuration for EVO PLL | From | Dmitry Baryshkov <> |
| |
On 01/06/2023 17:33, Jagadeesh Kona wrote: > Hi Dmitry, Konrad, > > On 5/26/2023 9:23 PM, Dmitry Baryshkov wrote: >> On 26/05/2023 12:33, Konrad Dybcio wrote: >>> >>> >>> On 25.05.2023 19:21, Jagadeesh Kona wrote: >>>> In lucid evo pll, the CAL_L field is part of L value register >>>> itself, and >>>> the l value configuration passed from clock controller driver includes >>>> CAL_L and L values as well. Hence remove explicit configuration of >>>> CAL_L >>>> for evo pll. >>>> >>>> Fixes: 260e36606a03 ("clk: qcom: clk-alpha-pll: add Lucid EVO PLL >>>> configuration interfaces") >>>> Signed-off-by: Taniya Das <quic_tdas@quicinc.com> >>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> >>>> --- >>> Oh that isn't obvious at first sight, nice find! >>> >>> I'd suggest a different solution though: >>> >>> #define LUCID_EVO_PLL_L_LVAL GENMASK(.. >>> #define LUCID_EVO_PLL_L_CAL_L GENMASK(.. >>> >>> lval = FIELD_PREP(LUCID_EVO_PLL_L_LVAL, config->l) | >>> FIELD_PREP(LUCID_EVO_PLL_L_CAL_L, config->cal_l); >>> >>> This would make the separation between the two parts more explicit >>> >>> however >>> >>> config->l would then represent the L value and not the end value >>> written to the L register >> >> Yes. I think there should be separate config->l and config->cal_l >> values (and probably ringosc_cal_l, basing on the comment in the source). >> Thanks for your suggestions. In all recent chipsets, L & CAL_L fields > are encapsulated in the same register, so we feel it is better to > directly pass the combined configuration value in config->l itself and > program it directly into register without any additional handling > required in pll driver code.
My feeling is that it is better to split it, since these are the different fields. The value .l = 0x4444003e doesn't mean anything per se.
Three values are much more meaningful: .l = 0x3e, .cal_l = 0x44, .ringosc_cal_l = 0x44,
Not to mention that this way you don't have to touch pll configuration for the existing Lucid EVO PLL. Not to mention that for the Lucid ole PLLs the cal_l and ringosc_cal_l values seem to be static (0x44), so there is no need to put them to the variable data.
> > Also the evo pll code is currently reused for both lucid evo and ole > pll's. Lucid ole PLL has an additional RINGOSC_CAL_L field along with L, > CAL_L fields in the same L register. By passing combined configuration > value in config->l itself, we feel we can avoid all the additional > handling required in PLL code. > >> Just a question: is camcc-sm8550 using the same PLL type or is it some >> kind of subtype of lucid_evo PLL? >> > No, it is not the same lucid evo PLL. It uses lucid ole PLL.
Then please don't reuse the clk_lucid_evo_pll_configure() call. You can add a new one, which will handle L/CAL_L/RINGOSC_CAL_L differences.
-- With best wishes Dmitry
| |