Received-SPF: pass (google.com: domain of linux-kernel+bounces-129640-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <af0dae12-c9aa-b0b0-67fd-f52d94566809@quicinc.com>
Date: Wed, 3 Apr 2024 16:37:41 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: [PATCH 1/7] clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for
 LUCID EVO PLL
Content-Language: en-US
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Dmitry Baryshkov
	<dmitry.baryshkov@linaro.org>
CC: Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd
	<sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
        Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio
	<konrad.dybcio@linaro.org>,
        Vinod Koul <vkoul@kernel.org>,
        Vladimir Zapolskiy
	<vladimir.zapolskiy@linaro.org>,
        <linux-arm-msm@vger.kernel.org>, <linux-clk@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, Taniya Das
	<quic_tdas@quicinc.com>,
        Jagadeesh Kona <quic_jkona@quicinc.com>,
        Imran Shaik
	<quic_imrashai@quicinc.com>,
        Satya Priya Kakitapalli
	<quic_skakitap@quicinc.com>
References: <20240330182817.3272224-1-quic_ajipan@quicinc.com>
 <20240330182817.3272224-2-quic_ajipan@quicinc.com>
 <d8c0ca00-7e14-454e-8a65-5dcf14ed7796@linaro.org>
 <e2f108d8-0b25-d799-fbe4-ab6256966982@quicinc.com>
 <da93a8ed-4fbb-488f-a1af-e701f7191fbd@linaro.org>
 <CAA8EJppB7dYvzeA0M6A_cN14FkC6K8WpLVoeE8NvytGcYDq5Pw@mail.gmail.com>
 <990d74fa-6d1d-4d64-b6fb-c68f5763c9d3@linaro.org>
From: Ajit Pandey <quic_ajipan@quicinc.com>
In-Reply-To: <990d74fa-6d1d-4d64-b6fb-c68f5763c9d3@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit


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
>