[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <41e31da2-5ea5-443f-a8f3-ef8280f25a00@oss.qualcomm.com>
Date: Thu, 30 Oct 2025 22:36:06 +0530
From: Taniya Das <taniya.das@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd
<sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
Ajit Pandey <ajit.pandey@....qualcomm.com>,
Imran Shaik <imran.shaik@....qualcomm.com>,
Jagadeesh Kona <jagadeesh.kona@....qualcomm.com>
Subject: Re: [PATCH v3 2/4] clk: qcom: ecpricc-qdu100: Add mem_enable_mask to
the clock memory branch
On 10/30/2025 4:41 PM, Konrad Dybcio wrote:
> On 10/30/25 7:24 AM, Taniya Das wrote:
>>
>>
>> On 10/24/2025 2:09 PM, Konrad Dybcio wrote:
>>> On 10/24/25 6:24 AM, Taniya Das wrote:
>>>> Add the newly introduced 'mem_enable_mask' to the memory control branch
>>>> clocks of ECPRI clock controller to align to the new mem_ops handling.
>>>>
>>>> Signed-off-by: Taniya Das <taniya.das@....qualcomm.com>
>>>> ---
>>>
>>> This probably fixes some ugly issue, could you please mention what
>>> the impact/problem is?
>>>
>> Konrad, this isn’t an issue. Previously, the ECPRI clock controller’s
>> mem_ops clocks used the mem_enable_ack_mask bit directly for both
>> setting and polling. However, this approach didn’t apply to newer
>> mem_ops clocks.
>
> Right, the videocc patch you attached makes use of this. I didn't notice
> previously.
>
>> Based on the feedback from v2, I’ve refactored the mem_ops code to
>> handle these cases more cleanly, which required updating the ECPRI
>> clocks as well.
>
> Please split the changes into:
>
> 1. add new struct fields, explaining the reason for the change
> 2. update the ECPRI driver (so that when the next patch lands the func
> isn't broken)
> 3. use the new fields in clk-branch.c now that all users (just qdu1000) have
> the required data filled in
>
> So that the platform remains functional at any point in time (which is a
> policy because it impacts bisect)
>
> 1&2 can be potentially squashed, potayto/potahto
>
Thanks Konrad, will update the changes accordingly.
--
Thanks,
Taniya Das
Powered by blists - more mailing lists