linux-kernel - Re: [PATCH RFC 1/3] arm64: dts: qcom: sm8750: Add Iris VPU v3.5

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: <4be1ebb7-1dc7-49e0-aa5d-621f023b3853@oss.qualcomm.com>
Date: Tue, 15 Jul 2025 12:50:44 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        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>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/3] arm64: dts: qcom: sm8750: Add Iris VPU v3.5

On 7/15/25 12:34 PM, Krzysztof Kozlowski wrote:
> On 15/07/2025 12:09, Konrad Dybcio wrote:
>> On 7/15/25 12:07 PM, Krzysztof Kozlowski wrote:
>>> On 15/07/2025 11:32, Krzysztof Kozlowski wrote:
>>>> On 14/07/2025 15:55, Krzysztof Kozlowski wrote:
>>>>> +
>>>>> +		videocc: clock-controller@...0000 {
>>>>> +			compatible = "qcom,sm8750-videocc";
>>>>> +			reg = <0x0 0x0aaf0000 0x0 0x10000>;
>>>>> +			clocks = <&bi_tcxo_div2>,
>>>>> +				 <&gcc GCC_VIDEO_AHB_CLK>;
>>>>> +			power-domains = <&rpmhpd RPMHPD_MMCX>;
>>>>
>>>> This is incomplete, need second power domain and I did not check against
>>>> qcom,sm8750-videocc schema before sending. I will send a v2 a bit later
>>>> (maybe some reviews pop up).
>>>
>>> Heh, no. The DTS here is correct. The videocc bindings are not correct
>>> (and that's not my patch).
>>
>> Well, you want two power domains here in either case..
> Are you sure? My point was one is correct and downstream confirms that
> in their bindings (which is a poor argument, I know). Which one would be
> the second? MM? We don't have such...

Historically clock controllers used a pair of CX/MX, with CX powering
the "meat" and MX powering the PLLs (& retention logic, IIUC).
Over time, CX was split into multiple usecase-specific domains (like
GFX), and we now have MMCX (or MM_CX - multimedia CX) for multimedia
hw specifically

In the downstream tree you're looking at, sun-regulators.dtsi aliases
VDD_MMCX_LEVEL as VDD_MM_LEVEL for $reasons, which is admittedly a
little confusing

MX has similarly been split into MXA (MX-Always [on]) and MXC
(MX-Collapsible). For Venus, you want the latter, as the hardware is
not crucial to the functioning of the SoC (the connection is of course
physically determined at SoC design stage, but it's a good heuristic
to keep in mind).

Konrad