linux-kernel - Re: [PATCH V4 8/8] arm64: dts: qcom: sm4450: add camera, display and gpu clock controller

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: <f9a23663-7a1d-44dc-8e0b-8463c3c88a29@linaro.org>
Date: Fri, 12 Jul 2024 14:40:37 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Ajit Pandey <quic_ajipan@...cinc.com>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
 Vinod Koul <vkoul@...nel.org>,
 Vladimir Zapolskiy <vladimir.zapolskiy@...aro.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>, Jagadeesh Kona <quic_jkona@...cinc.com>,
 Imran Shaik <quic_imrashai@...cinc.com>,
 Satya Priya Kakitapalli <quic_skakitap@...cinc.com>
Subject: Re: [PATCH V4 8/8] arm64: dts: qcom: sm4450: add camera, display and
 gpu clock controller

On 12.07.2024 2:31 PM, Ajit Pandey wrote:
> 
> 
> On 7/12/2024 5:52 PM, Konrad Dybcio wrote:
>> On 12.07.2024 11:53 AM, Ajit Pandey wrote:
>>>
>>>
>>> On 7/11/2024 3:25 PM, Konrad Dybcio wrote:
>>>> On 3.07.2024 11:16 AM, Ajit Pandey wrote:
>>>>>
>>>>>
>>>>> On 6/13/2024 1:11 PM, Konrad Dybcio wrote:
>>>>>>
>>>>>>
>>>>>> On 6/11/24 15:37, Ajit Pandey wrote:
>>>>>>> Add device node for camera, display and graphics clock controller on
>>>>>>> Qualcomm SM4450 platform.
>>>>>>>
>>>>>>> Signed-off-by: Ajit Pandey <quic_ajipan@...cinc.com>
>>>>>>> ---
>>>>>>
>>>>>> None of these nodes reference a power domain (which would usually be
>>>>>> CX/MX/MMCX). This way, the RPMhPDs will never be scaled.
>>>>>>
>>>>>> The current upstream implementation only allows one power domain to be
>>>>>> scaled, but that's better than none (see other DTs for recent SoCs).
>>>>>>
>>>>>> Konrad
>>>>>
>>>>> SM4450 doesn't support MMCX and CX/MX domains will remain active so
>>>>> power-domains property is actually not required for SM4450 clock nodes.
>>>>
>>>> It's not only about them being active.. some PLLs require e.g. MX to be
>>>> at a certain level, or the system will be unstable
>>>>
>>>> Konrad
>>>
>>> With active I mean CX/MX rails will be default running at minimum level required for clock controllers. Adding power-domains property for CX/MX rails is like a redundant code as that will also scale such rails at default specified minimum level only. Also we hadn't added such property for other targets DT nodes to scale up CX/MX at minimum level.
>>
>> What I mean here is that, the minimum level may not be enough. In such case
>> you would also add a required-opps = <&handle_to_rpmhpd_opp_level>
>>
>> Konrad
>>
> 
> Apologies, but could you please elaborate the use-case where minimum level isn't enough ? I guess for clock controllers configuration min level of CX/MX would be suffice, client will anyhow scale such rails to higher levels depending on their use-case.

The main issue here is with PLLs within the clock controllers. Nobody
votes for them. It's an unsolved problem and we currently work around
cases where it's necessary by requiring that (with runtime pm, so when
there's active consumers of the clock controller) the attached power
domain is at >= SOME_LEVEL

Konrad