linux-kernel - Re: [PATCH V2 RESEND 6/6] arm64: dts: qcom: sm8650: Add video and camera clock controllers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f8aa5b5e-b7c4-4ef4-ac45-de04c84b3fa4@quicinc.com>
Date: Thu, 18 Apr 2024 16:47:01 +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 4/5/2024 1:14 PM, Dmitry Baryshkov wrote:
> On Fri, 5 Apr 2024 at 09:01, Jagadeesh Kona <quic_jkona@...cinc.com> wrote:
>>
>>
>>
>> On 4/4/2024 9:35 PM, Dmitry Baryshkov wrote:
>>> On Thu, 4 Apr 2024 at 13:06, Jagadeesh Kona <quic_jkona@...cinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 4/4/2024 11:00 AM, Dmitry Baryshkov wrote:
>>>>> On Thu, 4 Apr 2024 at 08:13, Jagadeesh Kona <quic_jkona@...cinc.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/3/2024 9:24 PM, Dmitry Baryshkov wrote:
>>>>>>> On Wed, 3 Apr 2024 at 10:16, Jagadeesh Kona <quic_jkona@...cinc.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> In which cases? If it ends up with the retention vote, it is a bug
>>>>>>> which must be fixed.
>>>>>>>
>>>>>>
>>>>>> The minimum non-zero level(configured from bootloaders) of MMCX is
>>>>>> retention on few chipsets but it can vary across the chipsets. Hence to
>>>>>> be on safer side from our end, it is good to have required-opps in DT to
>>>>>> specify the minimum level required for this clock controller.
>>>>>
>>>>> We are discussing sm8650, not some abstract chipset. Does it list
>>>>> retention or low_svs as a minimal level for MMCX?
>>>>>
>>>>
>>>> Actually, the minimum level for MMCX is external to the clock
>>>> controllers.
>>>
>>> Yes, it comes from cmd-db
>>>
>>>>    But the clock controller requires MMCX to be atleast at
>>>> lowsvs for it to be functional.
>>>
>>> Correct
>>>
>>>> Hence we need to keep required-opps to
>>>> ensure the same without relying on the actual minimum level for MMCX.
>>>
>>> And this is not correct. There is no need for the DT to be redundant.
>>> I plan to send patches removing the existing required-opps when they
>>> are not required.
>>>

In my opinion, it is better not to remove the required-opps for the 
existing targets atleast since it may lead to some random clock issues 
if cmd-db minimum level is lower than the HW recommended voltage level 
clock controller requires.

>> I agree this is not required if cmd-db minimum level is already at
>> lowsvs. But since MMCX running at lowsvs is a mandatory requirement for
>> clock controller to operate, I believe it is good to have required-opps
>> to ensure we meet this requirement in all cases, rather than relying on
>> the cmd-db minimum level which we have no control over.
> 
> IIf we follow this logic, we should throw cmd-db away and hardcode all
> those values in the RPMh drivers.
> 
> We have cmd-db. If it is correct, there is no need to duplicate it. If
> it is incorrect, it is a bug that should be fixed or worked around.
> 

Sure will check and remove required-opps property for SM8650.

Thanks,
Jagadeesh