Re: [PATCH 3/5] arm64: dts: qcom: kaanapali: Add DisplayPort controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dts: qcom: mdss_dp0 incorrectly uses MX power domain instead of MMCX
--

commit 553dc7a911ae71f6e7c738ff40500145e878f936
Author: Balaji Kalkonda <balaji.kalkonda@oss.qualcomm.com>

arm64: dts: qcom: kaanapali: Add DisplayPort controller

This commit adds the device node for the DisplayPort controller on the
kaanapali platform. It configures the OPP table, clocks, power domain,
and connects it to the DPU and USB/DP QMP PHY.

> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index e48a179d07220..155c590c8eb60 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
[ ... ]
> @@ -3851,6 +3854,86 @@ mdss_dsi0_phy: phy@9ac1000 {
>  
>  				status = "disabled";
>  			};
> +
> +			mdss_dp0: displayport-controller@9ad2000 {
> +				compatible = "qcom,kaanapali-dp";
[ ... ]
> +				operating-points-v2 = <&dp_opp_table>;
> +
> +				power-domains = <&rpmhpd RPMHPD_MX>;

[Severity: High]
Should this power domain be RPMHPD_MMCX instead of RPMHPD_MX?

When the mdss_dp0 DisplayPort controller is active and changes link rates,
its performance state votes will scale the MX (memory) voltage rail instead
of the MMCX (multimedia) rail.

Since the display hardware physically resides on the MMCX rail, could this
misrouting cause the MMCX rail to be starved of the required voltage? This
appears like it could lead to under-voltage, silent hardware hangs, and
display corruption, while unnecessarily elevating the memory domain voltage.
Sibling display subsystem components like mdss_mdp and mdss_dsi0 typically
use RPMHPD_MMCX.

> +
> +				phys = <&usb_dp_qmpphy QMP_USB43DP_DP_PHY>;
> +				phy-names = "dp";
> +
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-kaanapali_dp-v1-0-6faeac3a6d59@oss.qualcomm.com?part=3