[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3464321-0c52-4c41-9198-e9e7b16aa419@quicinc.com>
Date: Wed, 3 Apr 2024 12:46:19 +0530
From: Jagadeesh Kona <quic_jkona@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio
<konrad.dybcio@...aro.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>,
Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
<linux-arm-msm@...r.kernel.org>, <linux-clk@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Taniya Das
<quic_tdas@...cinc.com>,
Satya Priya Kakitapalli <quic_skakitap@...cinc.com>,
Ajit Pandey <quic_ajipan@...cinc.com>,
Imran Shaik
<quic_imrashai@...cinc.com>
Subject: Re: [PATCH V2 RESEND 6/6] arm64: dts: qcom: sm8650: Add video and
camera clock controllers
On 3/25/2024 11:38 AM, Jagadeesh Kona wrote:
>
>
> On 3/21/2024 6:43 PM, Dmitry Baryshkov wrote:
>> On Thu, 21 Mar 2024 at 11:27, Jagadeesh Kona <quic_jkona@...cinc.com>
>> wrote:
>>>
>>> Add device nodes for video and camera clock controllers on Qualcomm
>>> SM8650 platform.
>>>
>>> Signed-off-by: Jagadeesh Kona <quic_jkona@...cinc.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/sm8650.dtsi | 28 ++++++++++++++++++++++++++++
>>> 1 file changed, 28 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
>>> b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>>> index 32c0a7b9aded..d862aa6be824 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>>> @@ -4,6 +4,8 @@
>>> */
>>>
>>> #include <dt-bindings/clock/qcom,rpmh.h>
>>> +#include <dt-bindings/clock/qcom,sm8450-videocc.h>
>>> +#include <dt-bindings/clock/qcom,sm8650-camcc.h>
>>> #include <dt-bindings/clock/qcom,sm8650-dispcc.h>
>>> #include <dt-bindings/clock/qcom,sm8650-gcc.h>
>>> #include <dt-bindings/clock/qcom,sm8650-gpucc.h>
>>> @@ -3110,6 +3112,32 @@ opp-202000000 {
>>> };
>>> };
>>>
>>> + videocc: clock-controller@...0000 {
>>> + compatible = "qcom,sm8650-videocc";
>>> + reg = <0 0x0aaf0000 0 0x10000>;
>>> + clocks = <&bi_tcxo_div2>,
>>> + <&gcc GCC_VIDEO_AHB_CLK>;
>>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>
>> The required-opps should no longer be necessary.
>>
>
> Sure, will check and remove this if not required.
I checked further on this and without required-opps, if there is no vote
on the power-domain & its peer from any other consumers, when runtime
get is called on device, it enables the power domain just at the minimum
non-zero level. But in some cases, the minimum non-zero level of
power-domain could be just retention and is not sufficient for clock
controller to operate, hence required-opps property is needed to specify
the minimum level required on power-domain for this clock controller.
Thanks,
Jagadeesh
>
>>> + #clock-cells = <1>;
>>> + #reset-cells = <1>;
>>> + #power-domain-cells = <1>;
>>> + };
>>> +
>>> + camcc: clock-controller@...0000 {
>>> + compatible = "qcom,sm8650-camcc";
>>> + reg = <0 0x0ade0000 0 0x20000>;
>>> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
>>> + <&bi_tcxo_div2>,
>>> + <&bi_tcxo_ao_div2>,
>>> + <&sleep_clk>;
>>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + #clock-cells = <1>;
>>> + #reset-cells = <1>;
>>> + #power-domain-cells = <1>;
>>> + };
>>> +
>>> mdss: display-subsystem@...0000 {
>>> compatible = "qcom,sm8650-mdss";
>>> reg = <0 0x0ae00000 0 0x1000>;
>>> --
>>> 2.43.0
>>>
>>>
>>
>>
Powered by blists - more mailing lists