lkml.org 
[lkml]   [2024]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/7] clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL
From


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
>


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