On Fri, 9 Jun 2023 at 14:50, Jagadeesh Kona <quic_jkona@xxxxxxxxxxx> wrote:
>
> Hi Dmitry,
>
> Thanks for your review!
>
> On 6/1/2023 8:13 PM, Dmitry Baryshkov wrote:
> > 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@xxxxxxxxxxx>
> >>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@xxxxxxxxxxx>
> >>>>> ---
> >>>> 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.
> >
>
> Sure, will keep the existing code as is and will remove this patch in
> the next series.
>
> >>
> >> 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.
> >
>
> The only difference between evo and ole pll configure is extra
> RINGOSC_CAL_L programming needed only for ole pll. We can achieve the
> same with clk_lucid_evo_pll_configure() itself by directly including
> RINGOSC_CAL_L field in L configuration for OLE PLL's.
Please don't, that's all I can say. Those are different fields. By
looking at the config->l one can calculate PLL rate. If you overload
the config->l with CAL_L and RINGOSC_CAL_L, the purpose of this field
is gone.
As the CAL_L and RINGOSC_CAL_L fields are static, just move them to
the clk_lucid_ole_pll_configure().
--
With best wishes
Dmitry
