Re: [PATCH v5 5/6] arm64: dts: qcom: sm8350: add Iris device

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `mmcx` power domain will not be dynamically scaled by the Venus driver, leading to hardware undervolting at high frequencies.
- [Low] The 'power-domains' and 'power-domain-names' properties specify 4 items, which violates the maximum limit of 3 in the dt-binding schema.
--

commit 046ca095899786006b3cdd62f346ab47c7c8bd55
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

arm64: dts: qcom: sm8350: add Iris device

This commit adds the Iris and video clock controller devices, describing the
Iris2 core present on the sm8350 platform.

> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> index 5c8fe213f5e4e..eedf677a7070d 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
[ ... ]
> @@ -2745,6 +2747,85 @@ usb_2_dwc3: usb@a800000 {
>  			};
>  		};
>  
> +		iris: video-codec@aa00000 {
> +			compatible = "qcom,sm8350-iris", "qcom,sm8250-venus";
> +			reg = <0x0 0x0aa00000 0x0 0x100000>;
> +			interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> +
> +			clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
> +				 <&videocc VIDEO_CC_MVS0C_CLK>,
> +				 <&videocc VIDEO_CC_MVS0_CLK>;
> +			clock-names = "iface",
> +				      "core",
> +				      "vcodec0_core";
> +			power-domains = <&videocc MVS0C_GDSC>,
> +					<&videocc MVS0_GDSC>,
> +					<&rpmhpd RPMHPD_MX>,
> +					<&rpmhpd RPMHPD_MMCX>;
> +			power-domain-names = "venus",
> +					     "vcodec0",
> +					     "mx",
> +					     "mmcx";

Does adding four items here violate the dt-binding schema?

The schema for the fallback compatible qcom,sm8250-venus enforces a maxItems
of 3 for power-domains, and restricts power-domain-names to exactly "venus",
"vcodec0", and "mx". This might cause dtbs_check validation failures.

[ ... ]
> +			iris_opp_table: opp-table {
> +				compatible = "operating-points-v2";
[ ... ]
> +				opp-444000000 {
> +					opp-hz = /bits/ 64 <444000000>;
> +					required-opps = <&rpmhpd_opp_svs_l1>,
> +							<&rpmhpd_opp_nom>;
> +				};

Will the mmcx power domain be dynamically scaled here?

Because this node relies on the fallback compatible qcom,sm8250-venus, the
Venus driver will probe it using the legacy sm8250_res struct, which hardcodes
its OPP power domains list to just "mx" with num_pd_names = 1.

Because the driver uses devm_pm_domain_attach_list() to attach domains by
name, mmcx is ignored and never attached to the device's OPP structure.

The generic OPP framework will therefore only apply the first required-opps
entry to mx and skip the second. When the hardware is clocked up to 444MHz,
mmcx will remain stuck at its lowest static voltage vote.

Could this lead to hardware undervolting and system crashes? Does the Venus
driver need a dedicated sm8350_res struct and updates to explicitly support
and attach the mmcx OPP power domain before enabling this node?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512-iris-sc8280xp-v5-0-8cc251e83b58@oss.qualcomm.com?part=5