[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a352b67b-4da9-d477-b953-b8003d4de91c@quicinc.com>
Date: Mon, 4 Sep 2023 20:14:23 +0530
From: Nitin Rawat <quic_nitirawa@...cinc.com>
To: Bjorn Andersson <quic_bjorande@...cinc.com>
CC: <mani@...nel.org>, <agross@...nel.org>, <andersson@...nel.org>,
<konrad.dybcio@...aro.org>, <jejb@...ux.ibm.com>,
<martin.petersen@...cle.com>, <quic_cang@...cinc.com>,
<quic_nguyenb@...cinc.com>, <linux-scsi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
"Naveen Kumar Goud Arepalli" <quic_narepall@...cinc.com>
Subject: Re: [PATCH V6 4/6] scsi: ufs: qcom: Align unipro clk attributes
configuration as per HPG
On 9/1/2023 9:13 PM, Bjorn Andersson wrote:
> On Fri, Sep 01, 2023 at 05:13:34PM +0530, Nitin Rawat wrote:
>> Currently CORE_CLK_1US_CYCLES, PA_VS_CORE_CLK_40NS_CYCLES are configured
>> in clk scaling post change ops.
>>
>> Move this to clk scaling pre change ops to align completely with hardware
>> specification. This doesn't bring any functionality change.
>>
>
> How can applying the clock scaling configuration, and "aligning with
> hardware specification" not "bring any functionality change"?
>
> If the code is called in a way where there is no difference between pre
> and post callbacks, then state that - but it begs the question, why do
> we have this "flexible" (complex) callback scheme if it doesn't matter.
>
> Regards,
> Bjorn
Hi Bjorn,
Here my intention is to align the sequence completely with HPG.
Functionality w.r.t to clock scaling is not impacted here.
I'll update the commit text to capture more details in next patchset.
Thanks,
Nitin
Powered by blists - more mailing lists