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?
Best regards,
Krzysztof
