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 <[email protected]> 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/[email protected]?part=3
