[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6fdde54e-12cb-442c-9dea-d1d6cbca340b@linaro.org>
Date: Mon, 5 Feb 2024 12:33:29 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: "Satya Priya Kakitapalli (Temp)" <quic_skakitap@...cinc.com>,
Bjorn Andersson <andersson@...nel.org>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Taniya Das <quic_tdas@...cinc.com>
Cc: linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Ajit Pandey <quic_ajipan@...cinc.com>,
Imran Shaik <quic_imrashai@...cinc.com>,
Jagadeesh Kona <quic_jkona@...cinc.com>
Subject: Re: [PATCH 2/3] clk: qcom: gcc-sm8150: Add gcc_parents_0_ao support
On 5.02.2024 09:37, Satya Priya Kakitapalli (Temp) wrote:
>
> On 1/25/2024 3:25 PM, Konrad Dybcio wrote:
>>
>>
>> On 1/25/24 06:49, Satya Priya Kakitapalli (Temp) wrote:
>>>
>>> On 1/23/2024 11:17 PM, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 1/23/24 17:34, Satya Priya Kakitapalli wrote:
>>>>> Add active_only support for gcc_parents_0, this is needed because
>>>>> some of the clocks under it are critical which would vote on xo
>>>>> blocking the suspend.
>>>>>
>>>>> Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@...cinc.com>
>>>>> ---
>>>>
>>>> Is there a need to keep gcc_cpuss_ahb_clk_src around? Do we do any
>>>> ratesetting on it? Should we ever turn it off?
>>>>
>>>
>>> The branch clocks under gcc_cpuss_ahb_clk_src are critical clocks, which are running at 19.2Mhz causing vote on XO during suspend. As of now no rate setting is happening but this rcg is useful to get the exact rates from debugfs. Hence this change is needed to avoid XO shutdown issues.
>>
>> So, if I underderstood you correctly, this clock serves no purpose other
>> than getting rate?
>>
>> In this case, I'd say we should de-register it from the clock driver and
>> use debugcc [1] (contributions welcome!) for precise measurements.
>>
>
> Although currently there is no rate-setting happening now, its better to keep the rcg modelling as is, considering that it might be needed if some use case arises in future.
We don't tend to solve imaginary problems, please lay out what it would be
used for, if at all. Then, we can assess whether it's necessary.
Konrad
Powered by blists - more mailing lists