[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <752f077d-68a8-4bb5-86cf-c6d49cfe4606@linaro.org>
Date: Thu, 18 Apr 2024 23:56:09 +0300
From: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>,
Jagadeesh Kona <quic_jkona@...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>
Cc: 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
Hi Konrad,
On 3/23/24 02:33, Konrad Dybcio wrote:
> On 21.03.2024 14:07, Vladimir Zapolskiy wrote:
>> Hello Jagadeesh,
>>
>> On 3/21/24 11:25, Jagadeesh Kona 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>;
>>
>> Please add default status = "disabled";
>>
>>> + #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>;
>>
>> Please add default status = "disabled";
>>
>>> + #clock-cells = <1>;
>>> + #reset-cells = <1>;
>>> + #power-domain-cells = <1>;
>>> + };
>>> +
>>> mdss: display-subsystem@...0000 {
>>> compatible = "qcom,sm8650-mdss";
>>> reg = <0 0x0ae00000 0 0x1000>;
>>
>> After disabling the clock controllers
>
> Clock controllers should never be disabled period, that defeats the
> entire point of having unused clk/pd cleanup.
hm, that's very sane, I didn't think about it from this point, thanks!
> The only reason for them to be disabled is for cases where platform
> crashes on access due to stinky "security" settings (like with audio
> clocks), or when people are too lazy to upstream panel drivers and
> end up partially upstreaming display-related changes and continue
> using the bootloader-initialized framebuffer. This takes away from
> the very little determinism we have.
>
--
Best wishes,
Vladimir
Powered by blists - more mailing lists