Re: [PATCH v5 3/6] arm64: dts: qcom: sc8280xp: Add Iris core

[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 be ignored by the fallback `sm8250-venus` driver, leaving the hardware under-volted at high frequencies, resulting in lockups or crashes.
- [Low] The `iris` device tree node specifies 4 power domains, violating the `qcom,sm8250-venus.yaml` schema constraints.
--

commit ae854de052f0b364828840ec87b770c30cfa8595
Author: Konrad Dybcio <konradybcio@kernel.org>

arm64: dts: qcom: sc8280xp: Add Iris core

This patch adds the required nodes to enable the Iris core on sc8280xp
devices.

> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index 41c57e7dc4333..d950816a9a9e1 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi

[ ... ]

> @@ -4181,6 +4189,97 @@ usb_1_dwc3_ss: endpoint {
>  			};
>  		};
>  
> +		iris: video-codec@aa00000 {
> +			compatible = "qcom,sc8280xp-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 SC8280XP_MX>,
> +					<&rpmhpd SC8280XP_MMCX>;
> +			power-domain-names = "venus",
> +					     "vcodec0",
> +					     "mx",
> +					     "mmcx";

The qcom,sm8250-venus.yaml schema currently enforces a maximum of 3 items
for power-domains (venus, vcodec0, and mx). Will adding the mmcx power
domain here cause make dtbs_check to fail validation, since the schema
hasn't been updated to accommodate a fourth domain?

> +
> +			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
> +				 <&videocc VIDEO_CC_MVS0C_CLK_ARES>;
> +			reset-names = "bus", "core";
> +
> +			interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> +					 &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> +					<&mmss_noc MASTER_VIDEO_P0 QCOM_ICC_TAG_ALWAYS
> +					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> +			interconnect-names = "cpu-cfg",
> +					     "video-mem";
> +
> +			operating-points-v2 = <&iris_opp_table>;
> +			iommus = <&apps_smmu 0x2a00 0x400>;
> +			memory-region = <&pil_video_mem>;
> +
> +			status = "disabled";
> +
> +			iris_opp_table: opp-table {
> +				compatible = "operating-points-v2";
> +
> +				opp-240000000 {
> +					opp-hz = /bits/ 64 <240000000>;
> +					required-opps = <&rpmhpd_opp_svs>,
> +							<&rpmhpd_opp_low_svs>;
> +				};

[ ... ]

> +				opp-560000000 {
> +					opp-hz = /bits/ 64 <560000000>;
> +					required-opps = <&rpmhpd_opp_nom>,
> +							<&rpmhpd_opp_turbo_l1>;
> +				};
> +			};

The opp-table defines two required-opps for each node, which expects the
driver to scale both the mx and mmcx domains.

However, since this node falls back to qcom,sm8250-venus, the venus driver
uses sm8250_res which hardcodes opp_pmdomain = { "mx" } and only attaches
the mx domain. The generic opp framework's _set_required_opps() will then
safely skip the unattached mmcx domain.

Could this leave the mmcx domain stuck at its default voltage (like low_svs
requested by videocc) while the core runs at 560MHz? Does this run the risk
of undervolting the hardware and causing lockups?

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