Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 3 Apr 2024 16:37:41 +0530 | Subject | Re: [PATCH 1/7] clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL | From | Ajit Pandey <> |
| |
On 4/3/2024 2:20 PM, Krzysztof Kozlowski wrote: > On 03/04/2024 10:37, Dmitry Baryshkov wrote: >> 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? >> OK, for the ease and more clarity I'll update the cover letter with fix details and required dependency on this feature in next series.
>> 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. > > No, I am not the first. It differs between subsystems and I do not > recall all folks, but the one person coming to my mind is Mark Brown who > expressed it numerous times. > > Best regards, > Krzysztof >
| ![\](/images/icornerr.gif) |