[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <97f5f5b1-b4f9-4d0d-88fb-4c7a0f1c26ac@quicinc.com>
Date: Mon, 20 Jan 2025 16:04:12 +0530
From: Taniya Das <quic_tdas@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio
<konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski
<krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Ajit Pandey
<quic_ajipan@...cinc.com>,
Imran Shaik <quic_imrashai@...cinc.com>,
"Jagadeesh Kona" <quic_jkona@...cinc.com>,
<linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] arm64: dts: qcom: Add cpu scaling clock node
On 1/20/2025 2:16 PM, Dmitry Baryshkov wrote:
>>> This doesn't follow the bindings, does it?
>> I will add and re-use the closest target compatible.
>>
>>>> + reg = <0 0x18323000 0 0x1400>,
>>>> + <0 0x18325800 0 0x1400>;
>>>> + reg-names = "freq-domain0", "freq-domain1";
>>>> +
>>>> + clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
>>>> + clock-names = "xo", "alternate";
>>> Are the DCVSH interrupts?
>>>
>> This target does not have DCVSH interrupts directly connected to the
>> CPUFREQ-HW.
> So, does it require a separate LMH driver, like the one used for sdm845?
I will check how it is handled on QCS615 as it is closer to SC7180 and I
didn't see any LMH handling there as well.
--
Thanks & Regards,
Taniya Das.
Powered by blists - more mailing lists