lkml.org 
[lkml]   [2024]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 1/7] clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL
    On Wed, 3 Apr 2024 at 09:49, Krzysztof Kozlowski
    <krzysztof.kozlowski@linaro.org> wrote:
    >
    > On 02/04/2024 20:35, Ajit Pandey wrote:
    > >
    > >
    > > On 3/31/2024 12:49 AM, Krzysztof Kozlowski wrote:
    > >> On 30/03/2024 19:28, Ajit Pandey wrote:
    > >>> In LUCID EVO PLL CAL_L_VAL and L_VAL bitfields are part of single
    > >>> PLL_L_VAL register. Update for L_VAL bitfield values in PLL_L_VAL
    > >>> register using regmap_write() API in __alpha_pll_trion_set_rate
    > >>> callback will override LUCID EVO PLL initial configuration related
    > >>> to PLL_CAL_L_VAL bit fields in PLL_L_VAL register.
    > >>>
    > >>> Observed random PLL lock failures during PLL enable due to such
    > >>> override in PLL calibration value. Use regmap_update_bits() with
    > >>> L_VAL bitfield mask instead of regmap_write() API to update only
    > >>> PLL_L_VAL bitfields in __alpha_pll_trion_set_rate callback.
    > >>>
    > >>> Fixes: 260e36606a03 ("clk: qcom: clk-alpha-pll: add Lucid EVO PLL configuration interfaces")
    > >>>
    > >>
    > >> No blank lines between tags.
    > >>
    > >> Add Cc-stable tag.
    > >>
    > > Sure, will update in next series
    > >
    > >> Please do not combine fixes with new features.
    > >> > Best regards,
    > >> Krzysztof
    > >>
    > >
    > > Actually this fix is required for correct scaling for few frequencies in
    > > this patch series, hence combined them together and pushed this fix as
    > > first patch in series so that they get mainlined together and feature
    > > functionality will not get impacted.
    >
    > OK, that's fine but usual way is that such need is expressed in the
    > cover letter, so maintainer will know what to do. What if this patch
    > should go to fixes and rest normally to for-next? How do you expect
    > maintainer to apply the patch? Entire thread and then manually move the
    > commits? Why making it so complicated for the maintainers?

    Huh? I think it's pretty normal to have fixes in front of the patch
    series. Having it in the middle would be troublesome indeed. You are
    the first person to complain.

    --
    With best wishes

    Dmitry

    \
     
     \ /
      Last update: 2024-05-27 16:20    [W:3.981 / U:0.460 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site