[PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[Krzysztof Kozlowski]

Dependency
==========
Depends on USB patches, which are being reviewed, therefore marking it
as RFC as it cannot be applied.
https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/

Unmerged bindings used here
===========================
dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
(DRM MDSS bindings were applied)

Description
===========
I did not enable DisplayPort because it does not work on my board and I
don't know why. I double checked QMP combo phy and other bits, and
everything is looking fine, but still no USB display, so maybe I miss
some other dependencies as this is early upstream.

DSI panel works fine.

HDMI is not yet ready, because of lack of hardware with HDMI.

Best regards,
Krzysztof

---
Krzysztof Kozlowski (2):
      arm64: dts: qcom: eliza: Add display (MDSS) with Display CC
      arm64: dts: qcom: eliza-mtp: Enable DSI display panel

 arch/arm64/boot/dts/qcom/eliza-mtp.dts |  63 +++++
 arch/arm64/boot/dts/qcom/eliza.dtsi    | 433 +++++++++++++++++++++++++++++++++
 2 files changed, 496 insertions(+)
---
base-commit: 1f68839a688f612e0dc183559adf9161f15db297
change-id: 20260327-dts-qcom-eliza-display-64de3cfc8a50
prerequisite-change-id: 20260330-eliza-adsp-usb-8ef2b1b0fc13:v1
prerequisite-patch-id: e0744310fa58e080587218e62aa6686ed841689f
prerequisite-patch-id: 1b4e40eb33adf28c8b6105f25f6636f82239a962
prerequisite-patch-id: 4671af784a83f9ce69cc2c502912698476ee7719

Best regards,
--  
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

[PATCH RFC 1/2] arm64: dts: qcom: eliza: Add display (MDSS) with Display CC

[Krzysztof Kozlowski]

Add device nodes for almost entire display: MDSS, DPU, DSI, DSI PHYs,
DisplayPort and Display Clock Controller.

Missing pieces are HDMI PHY and HDMI controller.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

---

Lack of hardware for HDMI testing, but the work on drivers is in
progress.
---
 arch/arm64/boot/dts/qcom/eliza.dtsi | 433 ++++++++++++++++++++++++++++++++++++
 1 file changed, 433 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 37baa4b240d6..e9b522b88690 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -3,6 +3,8 @@
  * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
  */
 
+#include <dt-bindings/clock/qcom,dsi-phy-28nm.h>
+#include <dt-bindings/clock/qcom,eliza-dispcc.h>
 #include <dt-bindings/clock/qcom,eliza-gcc.h>
 #include <dt-bindings/clock/qcom,eliza-tcsr.h>
 #include <dt-bindings/clock/qcom,rpmh.h>
@@ -1035,6 +1037,7 @@ port@2 {
 					reg = <2>;
 
 					usb_dp_qmpphy_dp_in: endpoint {
+						remote-endpoint = <&mdss_dp0_out>;
 					};
 				};
 			};
@@ -1131,6 +1134,436 @@ usb_dwc3_ss: endpoint {
 			};
 		};
 
+		mdss: display-subsystem@ae00000 {
+			compatible = "qcom,eliza-mdss";
+			reg = <0x0 0x0ae00000 0x0 0x1000>;
+			reg-names = "mdss";
+			ranges;
+
+			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+
+			clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+				 <&gcc GCC_DISP_HF_AXI_CLK>,
+				 <&dispcc DISP_CC_MDSS_MDP_CLK>;
+
+			resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+
+			interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+					<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+			interconnect-names = "mdp0-mem",
+					     "cpu-cfg";
+
+			power-domains = <&dispcc MDSS_GDSC>;
+
+			iommus = <&apps_smmu 0x800 0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <1>;
+
+			#address-cells = <2>;
+			#size-cells = <2>;
+
+			status = "disabled";
+
+			mdss_mdp: display-controller@ae01000 {
+				compatible = "qcom,eliza-dpu";
+				reg = <0x0 0x0ae01000 0x0 0x93000>,
+				      <0x0 0x0aeb0000 0x0 0x2008>;
+				reg-names = "mdp",
+					    "vbif";
+
+				interrupts-extended = <&mdss 0>;
+
+				clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+					 <&dispcc DISP_CC_MDSS_AHB_CLK>,
+					 <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+					 <&dispcc DISP_CC_MDSS_MDP_CLK>,
+					 <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+				clock-names = "nrt_bus",
+					      "iface",
+					      "lut",
+					      "core",
+					      "vsync";
+
+				assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+				assigned-clock-rates = <19200000>;
+
+				operating-points-v2 = <&mdp_opp_table>;
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+
+						dpu_intf1_out: endpoint {
+							remote-endpoint = <&mdss_dsi0_in>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
+
+						dpu_intf2_out: endpoint {
+							remote-endpoint = <&mdss_dsi1_in>;
+						};
+					};
+
+					port@2 {
+						reg = <2>;
+
+						dpu_intf0_out: endpoint {
+							remote-endpoint = <&mdss_dp0_in>;
+						};
+					};
+					/* TODO: HDMI */
+				};
+
+				mdp_opp_table: opp-table {
+					compatible = "operating-points-v2";
+
+					opp-150000000 {
+						opp-hz = /bits/ 64 <150000000>;
+						required-opps = <&rpmhpd_opp_low_svs_d1>;
+					};
+
+					opp-207000000 {
+						opp-hz = /bits/ 64 <207000000>;
+						required-opps = <&rpmhpd_opp_low_svs>;
+					};
+
+					opp-342000000 {
+						opp-hz = /bits/ 64 <342000000>;
+						required-opps = <&rpmhpd_opp_svs>;
+					};
+
+					opp-417000000 {
+						opp-hz = /bits/ 64 <417000000>;
+						required-opps = <&rpmhpd_opp_svs_l1>;
+					};
+
+					opp-532000000 {
+						opp-hz = /bits/ 64 <532000000>;
+						required-opps = <&rpmhpd_opp_nom>;
+					};
+
+					opp-600000000 {
+						opp-hz = /bits/ 64 <600000000>;
+						required-opps = <&rpmhpd_opp_nom_l1>;
+					};
+
+					opp-660000000 {
+						opp-hz = /bits/ 64 <660000000>;
+						required-opps = <&rpmhpd_opp_turbo>;
+					};
+				};
+			};
+
+			mdss_dsi0: dsi@ae94000 {
+				compatible = "qcom,eliza-dsi-ctrl", "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+				reg = <0x0 0x0ae94000 0x0 0x400>;
+				reg-names = "dsi_ctrl";
+
+				interrupts-extended = <&mdss 4>;
+
+				clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+					 <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+					 <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+					 <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+					 <&dispcc DISP_CC_MDSS_AHB_CLK>,
+					 <&gcc GCC_DISP_HF_AXI_CLK>,
+					 <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>,
+					 <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
+					 <&dispcc DISP_CC_ESYNC0_CLK>,
+					 <&dispcc DISP_CC_OSC_CLK>,
+					 <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+					 <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+				clock-names = "byte",
+					      "byte_intf",
+					      "pixel",
+					      "core",
+					      "iface",
+					      "bus",
+					      "dsi_pll_pixel",
+					      "dsi_pll_byte",
+					      "esync",
+					      "osc",
+					      "byte_src",
+					      "pixel_src";
+
+				operating-points-v2 = <&mdss_dsi_opp_table>;
+
+				phys = <&mdss_dsi0_phy>;
+				phy-names = "dsi";
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				status = "disabled";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+
+						mdss_dsi0_in: endpoint {
+							remote-endpoint = <&dpu_intf1_out>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
+
+						mdss_dsi0_out: endpoint {
+						};
+					};
+				};
+
+				mdss_dsi_opp_table: opp-table {
+					compatible = "operating-points-v2";
+
+					opp-140630000 {
+						opp-hz = /bits/ 64 <140630000>;
+						required-opps = <&rpmhpd_opp_low_svs_d1>;
+					};
+
+					opp-187500000 {
+						opp-hz = /bits/ 64 <187500000>;
+						required-opps = <&rpmhpd_opp_low_svs>;
+					};
+
+					opp-300000000 {
+						opp-hz = /bits/ 64 <300000000>;
+						required-opps = <&rpmhpd_opp_svs>;
+					};
+
+					opp-358000000 {
+						opp-hz = /bits/ 64 <358000000>;
+						required-opps = <&rpmhpd_opp_svs_l1>;
+					};
+				};
+			};
+
+			mdss_dsi0_phy: phy@ae95000 {
+				compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm";
+				reg = <0x0 0x0ae95000 0x0 0x200>,
+				      <0x0 0x0ae95200 0x0 0x280>,
+				      <0x0 0x0ae95500 0x0 0x400>;
+				reg-names = "dsi_phy",
+					    "dsi_phy_lane",
+					    "dsi_pll";
+
+				clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+					 <&bi_tcxo_div2>;
+				clock-names = "iface",
+					      "ref";
+
+				#clock-cells = <1>;
+				#phy-cells = <0>;
+
+				status = "disabled";
+			};
+
+			mdss_dsi1: dsi@ae96000 {
+				compatible = "qcom,eliza-dsi-ctrl", "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+				reg = <0x0 0x0ae96000 0x0 0x400>;
+				reg-names = "dsi_ctrl";
+
+				interrupts-extended = <&mdss 5>;
+
+				clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+					 <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+					 <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+					 <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+					 <&dispcc DISP_CC_MDSS_AHB_CLK>,
+					 <&gcc GCC_DISP_HF_AXI_CLK>,
+					 <&mdss_dsi1_phy DSI_PIXEL_PLL_CLK>,
+					 <&mdss_dsi1_phy DSI_BYTE_PLL_CLK>,
+					 <&dispcc DISP_CC_ESYNC1_CLK>,
+					 <&dispcc DISP_CC_OSC_CLK>,
+					 <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+					 <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+				clock-names = "byte",
+					      "byte_intf",
+					      "pixel",
+					      "core",
+					      "iface",
+					      "bus",
+					      "dsi_pll_pixel",
+					      "dsi_pll_byte",
+					      "esync",
+					      "osc",
+					      "byte_src",
+					      "pixel_src";
+
+				operating-points-v2 = <&mdss_dsi_opp_table>;
+
+				phys = <&mdss_dsi1_phy>;
+				phy-names = "dsi";
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				status = "disabled";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+
+						mdss_dsi1_in: endpoint {
+							remote-endpoint = <&dpu_intf2_out>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
+
+						mdss_dsi1_out: endpoint {
+						};
+					};
+				};
+			};
+
+			mdss_dsi1_phy: phy@ae97000 {
+				compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm";
+				reg = <0x0 0x0ae97000 0x0 0x200>,
+				      <0x0 0x0ae97200 0x0 0x280>,
+				      <0x0 0x0ae97500 0x0 0x400>;
+				reg-names = "dsi_phy",
+					    "dsi_phy_lane",
+					    "dsi_pll";
+
+				clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+					 <&rpmhcc RPMH_CXO_CLK>;
+				clock-names = "iface",
+					      "ref";
+
+				#clock-cells = <1>;
+				#phy-cells = <0>;
+
+				status = "disabled";
+			};
+
+			mdss_dp0: displayport-controller@af54000 {
+				compatible = "qcom,eliza-dp", "qcom,sm8650-dp";
+				reg = <0x0 0xaf54000 0x0 0x104>,
+				      <0x0 0xaf54200 0x0 0xc0>,
+				      <0x0 0xaf55000 0x0 0x770>,
+				      <0x0 0xaf56000 0x0 0x9c>,
+				      <0x0 0xaf57000 0x0 0x9c>;
+
+				interrupts-extended = <&mdss 12>;
+
+				clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+					 <&dispcc DISP_CC_MDSS_DPTX0_AUX_CLK>,
+					 <&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK>,
+					 <&dispcc DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
+					 <&dispcc DISP_CC_MDSS_DPTX0_PIXEL0_CLK>,
+					 <&dispcc DISP_CC_MDSS_DPTX0_PIXEL1_CLK>;
+				clock-names = "core_iface",
+					      "core_aux",
+					      "ctrl_link",
+					      "ctrl_link_iface",
+					      "stream_pixel",
+					      "stream_1_pixel";
+
+				assigned-clocks = <&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
+						  <&dispcc DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>,
+						  <&dispcc DISP_CC_MDSS_DPTX0_PIXEL1_CLK_SRC>;
+				assigned-clock-parents = <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+							 <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
+							 <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+				operating-points-v2 = <&dp_opp_table>;
+
+				phys = <&usb_dp_qmpphy QMP_USB43DP_DP_PHY>;
+				phy-names = "dp";
+
+				#sound-dai-cells = <0>;
+
+				status = "disabled";
+
+				dp_opp_table: opp-table {
+					compatible = "operating-points-v2";
+
+					opp-270000000 {
+						opp-hz = /bits/ 64 <270000000>;
+						required-opps = <&rpmhpd_opp_low_svs>;
+					};
+
+					opp-540000000 {
+						opp-hz = /bits/ 64 <540000000>;
+						required-opps = <&rpmhpd_opp_svs_l1>;
+					};
+
+					opp-810000000 {
+						opp-hz = /bits/ 64 <810000000>;
+						required-opps = <&rpmhpd_opp_nom>;
+					};
+				};
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+
+						mdss_dp0_in: endpoint {
+							remote-endpoint = <&dpu_intf0_out>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
+
+						mdss_dp0_out: endpoint {
+							data-lanes = <0 1 2 3>;
+							remote-endpoint = <&usb_dp_qmpphy_dp_in>;
+						};
+					};
+				};
+			};
+		};
+
+		dispcc: clock-controller@af00000 {
+			compatible = "qcom,eliza-dispcc";
+			reg = <0x0 0x0af00000 0x0 0x20000>;
+
+			clocks = <&bi_tcxo_div2>,
+				 <&bi_tcxo_ao_div2>,
+				 <&gcc GCC_DISP_AHB_CLK>,
+				 <&sleep_clk>,
+				 <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
+				 <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>,
+				 <&mdss_dsi1_phy DSI_BYTE_PLL_CLK>,
+				 <&mdss_dsi1_phy DSI_PIXEL_PLL_CLK>,
+				 <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+				 <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
+				 <0>, /* dp1 */
+				 <0>,
+				 <0>, /* dp2 */
+				 <0>,
+				 <0>, /* dp3 */
+				 <0>,
+				 <0>; /* HDMI phy */
+
+			power-domains = <&rpmhpd RPMHPD_MX>;
+			required-opps = <&rpmhpd_opp_low_svs>;
+
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+			#power-domain-cells = <1>;
+		};
+
 		pdc: interrupt-controller@b220000 {
 			compatible = "qcom,eliza-pdc", "qcom,pdc";
 			reg = <0x0 0x0b220000 0x0 0x40000>,

-- 
2.51.0

Re: [PATCH RFC 1/2] arm64: dts: qcom: eliza: Add display (MDSS) with Display CC

[Dmitry Baryshkov]

On Tue, Mar 31, 2026 at 04:02:49PM +0200, Krzysztof Kozlowski wrote:
> Add device nodes for almost entire display: MDSS, DPU, DSI, DSI PHYs,
> DisplayPort and Display Clock Controller.
> 
> Missing pieces are HDMI PHY and HDMI controller.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH RFC 1/2] arm64: dts: qcom: eliza: Add display (MDSS) with Display CC

[Konrad Dybcio]

On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
> Add device nodes for almost entire display: MDSS, DPU, DSI, DSI PHYs,
> DisplayPort and Display Clock Controller.
> 
> Missing pieces are HDMI PHY and HDMI controller.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> 
> ---

[...]

> +			mdss_mdp: display-controller@ae01000 {
> +				compatible = "qcom,eliza-dpu";
> +				reg = <0x0 0x0ae01000 0x0 0x93000>,
> +				      <0x0 0x0aeb0000 0x0 0x2008>;

sz=0x3000

[...]

> +			mdss_dsi0: dsi@ae94000 {
> +				compatible = "qcom,eliza-dsi-ctrl", "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl";

linebreak?

> +				reg = <0x0 0x0ae94000 0x0 0x400>;
> +				reg-names = "dsi_ctrl";
> +
> +				interrupts-extended = <&mdss 4>;
> +
> +				clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
> +					 <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
> +					 <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
> +					 <&dispcc DISP_CC_MDSS_ESC0_CLK>,
> +					 <&dispcc DISP_CC_MDSS_AHB_CLK>,
> +					 <&gcc GCC_DISP_HF_AXI_CLK>,
> +					 <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>,
> +					 <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
> +					 <&dispcc DISP_CC_ESYNC0_CLK>,
> +					 <&dispcc DISP_CC_OSC_CLK>,
> +					 <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
> +					 <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;

Why the source clocks?

[...]

> +			mdss_dsi0_phy: phy@ae95000 {
> +				compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm";
> +				reg = <0x0 0x0ae95000 0x0 0x200>,
> +				      <0x0 0x0ae95200 0x0 0x280>,

sz=0x300

[...]

> +			mdss_dp0: displayport-controller@af54000 {
> +				compatible = "qcom,eliza-dp", "qcom,sm8650-dp";
> +				reg = <0x0 0xaf54000 0x0 0x104>,

please pad the addr to 8 hex digits

sz=0x200

> +				      <0x0 0xaf54200 0x0 0xc0>,

sz=0x200

> +				      <0x0 0xaf55000 0x0 0x770>,

sz=0xc00
> +				      <0x0 0xaf56000 0x0 0x9c>,

sz=0x400
> +				      <0x0 0xaf57000 0x0 0x9c>;

sz=0x400

Also missing regs for quad-MST (Pixel2/3 @ 0x0af5_[89]000, each 0x400-long
and MST2/3_link @ 0x0af5_[ab]000, 0x600-long). I don't know if the DPU can
do quad-MST but there's registers..

Konrad

Re: [PATCH RFC 1/2] arm64: dts: qcom: eliza: Add display (MDSS) with Display CC

[Krzysztof Kozlowski]

On 02/04/2026 11:42, Konrad Dybcio wrote:
> On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
>> Add device nodes for almost entire display: MDSS, DPU, DSI, DSI PHYs,
>> DisplayPort and Display Clock Controller.
>>
>> Missing pieces are HDMI PHY and HDMI controller.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> ---
> 
> [...]
> 
>> +			mdss_mdp: display-controller@ae01000 {
>> +				compatible = "qcom,eliza-dpu";
>> +				reg = <0x0 0x0ae01000 0x0 0x93000>,
>> +				      <0x0 0x0aeb0000 0x0 0x2008>;
> 
> sz=0x3000
> 
> [...]

Thanks, I will double check with spec.

> 
>> +			mdss_dsi0: dsi@ae94000 {
>> +				compatible = "qcom,eliza-dsi-ctrl", "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl";
> 
> linebreak?
> 
>> +				reg = <0x0 0x0ae94000 0x0 0x400>;
>> +				reg-names = "dsi_ctrl";
>> +
>> +				interrupts-extended = <&mdss 4>;
>> +
>> +				clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
>> +					 <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
>> +					 <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
>> +					 <&dispcc DISP_CC_MDSS_ESC0_CLK>,
>> +					 <&dispcc DISP_CC_MDSS_AHB_CLK>,
>> +					 <&gcc GCC_DISP_HF_AXI_CLK>,
>> +					 <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>,
>> +					 <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
>> +					 <&dispcc DISP_CC_ESYNC0_CLK>,
>> +					 <&dispcc DISP_CC_OSC_CLK>,
>> +					 <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
>> +					 <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
> 
> Why the source clocks?

Short answer: because SM8750 binding requires it and that's the
same/derivative as indicated by compatibles.

Typical mailing list answer when people do not have any arguments: But
Kaanapali has the same!

Long answer: because that's how we represent the parent clocks in ABI
for the kernel. IOW, assigned-clocks do not work :(.

Rationale is in the 34bdf809a567ccefa1984ccda010c4b5de6c68c8 commit.

> 
> [...]
> 
>> +			mdss_dsi0_phy: phy@ae95000 {
>> +				compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm";
>> +				reg = <0x0 0x0ae95000 0x0 0x200>,
>> +				      <0x0 0x0ae95200 0x0 0x280>,
> 
> sz=0x300
> 
> [...]
> 
>> +			mdss_dp0: displayport-controller@af54000 {
>> +				compatible = "qcom,eliza-dp", "qcom,sm8650-dp";
>> +				reg = <0x0 0xaf54000 0x0 0x104>,
> 
> please pad the addr to 8 hex digits
> 
> sz=0x200
> 
>> +				      <0x0 0xaf54200 0x0 0xc0>,
> 
> sz=0x200
> 
>> +				      <0x0 0xaf55000 0x0 0x770>,
> 
> sz=0xc00
>> +				      <0x0 0xaf56000 0x0 0x9c>,
> 
> sz=0x400
>> +				      <0x0 0xaf57000 0x0 0x9c>;
> 
> sz=0x400
> 
> Also missing regs for quad-MST (Pixel2/3 @ 0x0af5_[89]000, each 0x400-long
> and MST2/3_link @ 0x0af5_[ab]000, 0x600-long). I don't know if the DPU can
> do quad-MST but there's registers..

OK, let me look at datasheet again.


Best regards,
Krzysztof

[PATCH RFC 2/2] arm64: dts: qcom: eliza-mtp: Enable DSI display panel

[Krzysztof Kozlowski]

Enable display on Eliza MTP board with Visionox VTDR6130 panel.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/eliza-mtp.dts | 63 ++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/eliza-mtp.dts b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
index c31f00e36eee..df0cfffcef61 100644
--- a/arch/arm64/boot/dts/qcom/eliza-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
@@ -417,6 +417,48 @@ vreg_l7k: ldo7 {
 	};
 };
 
+&mdss {
+	status = "okay";
+};
+
+&mdss_dsi0 {
+	vdda-supply = <&vreg_l4b>;
+
+	status = "okay";
+
+	panel@0 {
+		compatible = "visionox,vtdr6130";
+		reg = <0>;
+
+		reset-gpios = <&tlmm 12 GPIO_ACTIVE_LOW>;
+
+		vci-supply = <&vreg_l19b>;
+		vdd-supply = <&vreg_l1g>;
+		vddio-supply = <&vreg_l8b>;
+
+		pinctrl-0 = <&disp0_reset_n_active>, <&mdp_vsync>;
+		pinctrl-1 = <&disp0_reset_n_suspend>, <&mdp_vsync>;
+		pinctrl-names = "default", "sleep";
+
+		port {
+			panel0_in: endpoint {
+				remote-endpoint = <&mdss_dsi0_out>;
+			};
+		};
+	};
+};
+
+&mdss_dsi0_out {
+	remote-endpoint = <&panel0_in>;
+	data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+	vdds-supply = <&vreg_l2b>;
+
+	status = "okay";
+};
+
 &pm7550ba_eusb2_repeater {
 	vdd18-supply = <&vreg_l7b>;
 	vdd3-supply = <&vreg_l17b>;
@@ -433,6 +475,27 @@ &tlmm {
 	gpio-reserved-ranges = <20 4>,   /* NFC SPI */
 			       <111 2>,  /* WCN UART1 */
 			       <118 1>;  /* NFC Secure I/O */
+
+	disp0_reset_n_active: disp0-reset-n-active-state {
+		pins = "gpio12";
+		function = "gpio";
+		drive-strength = <8>;
+		bias-disable;
+	};
+
+	disp0_reset_n_suspend: disp0-reset-n-suspend-state {
+		pins = "gpio12";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-pull-down;
+	};
+
+	mdp_vsync: mdp-vsync-state {
+		pins = "gpio17";
+		function = "mdp_vsync";
+		drive-strength = <2>;
+		bias-pull-down;
+	};
 };
 
 &uart14 {

-- 
2.51.0

Re: [PATCH RFC 2/2] arm64: dts: qcom: eliza-mtp: Enable DSI display panel

[Dmitry Baryshkov]

On Tue, Mar 31, 2026 at 04:02:50PM +0200, Krzysztof Kozlowski wrote:
> Enable display on Eliza MTP board with Visionox VTDR6130 panel.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/eliza-mtp.dts | 63 ++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[Krzysztof Kozlowski]

On 31/03/2026 16:02, Krzysztof Kozlowski wrote:
> Dependency
> ==========
> Depends on USB patches, which are being reviewed, therefore marking it
> as RFC as it cannot be applied.
> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
> 
> Unmerged bindings used here
> ===========================
> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
> (DRM MDSS bindings were applied)

I missed update from Bjorn - the dispcc bindings were merged, so the DTS
depends on that branch with clock headers.

Best regards,
Krzysztof

Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[Konrad Dybcio]

On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
> Dependency
> ==========
> Depends on USB patches, which are being reviewed, therefore marking it
> as RFC as it cannot be applied.
> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
> 
> Unmerged bindings used here
> ===========================
> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
> (DRM MDSS bindings were applied)
> 
> Description
> ===========
> I did not enable DisplayPort because it does not work on my board and I
> don't know why. I double checked QMP combo phy and other bits, and
> everything is looking fine, but still no USB display, so maybe I miss
> some other dependencies as this is early upstream.

What was the furthest that you got? We can certainly try to help..

Got USB Type-C mode mux events?
PHY initialized and configured to 2/4-lane DP mode?
Are the AUX transfers failling?

Konrad

Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[Krzysztof Kozlowski]

On 31/03/2026 16:49, Konrad Dybcio wrote:
> On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
>> Dependency
>> ==========
>> Depends on USB patches, which are being reviewed, therefore marking it
>> as RFC as it cannot be applied.
>> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>>
>> Unmerged bindings used here
>> ===========================
>> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
>> (DRM MDSS bindings were applied)
>>
>> Description
>> ===========
>> I did not enable DisplayPort because it does not work on my board and I
>> don't know why. I double checked QMP combo phy and other bits, and
>> everything is looking fine, but still no USB display, so maybe I miss
>> some other dependencies as this is early upstream.
> 
> What was the furthest that you got? We can certainly try to help..
> 
> Got USB Type-C mode mux events?
> PHY initialized and configured to 2/4-lane DP mode?
> Are the AUX transfers failling?

[   43.975329] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
[   43.975410] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
[   45.780383] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
[   45.780463] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
[   45.780521] msm_dpu ae01000.display-controller: [drm:msm_dp_pm_runtime_suspend] type=10 core_init=1 phy_init=1

pastebin: https://pastebin.com/BVXy3Qeq

Abel pointed me to the phy problems, so I focused on that.
HSR says it is exactly same programming sequence as SM8650
and such was used.

Just note, that we have ADSP remoteproc up, but no audio including USB mux,
although that should not affect this, AFAIU.

Best regards,
Krzysztof

Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[Konrad Dybcio]

On 3/31/26 5:01 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 16:49, Konrad Dybcio wrote:
>> On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
>>> Dependency
>>> ==========
>>> Depends on USB patches, which are being reviewed, therefore marking it
>>> as RFC as it cannot be applied.
>>> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>>>
>>> Unmerged bindings used here
>>> ===========================
>>> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
>>> (DRM MDSS bindings were applied)
>>>
>>> Description
>>> ===========
>>> I did not enable DisplayPort because it does not work on my board and I
>>> don't know why. I double checked QMP combo phy and other bits, and
>>> everything is looking fine, but still no USB display, so maybe I miss
>>> some other dependencies as this is early upstream.
>>
>> What was the furthest that you got? We can certainly try to help..
>>
>> Got USB Type-C mode mux events?
>> PHY initialized and configured to 2/4-lane DP mode?
>> Are the AUX transfers failling?
> 
> [   43.975329] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
> [   43.975410] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
> [   45.780383] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
> [   45.780463] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
> [   45.780521] msm_dpu ae01000.display-controller: [drm:msm_dp_pm_runtime_suspend] type=10 core_init=1 phy_init=1
> 
> pastebin: https://pastebin.com/BVXy3Qeq
> 
> Abel pointed me to the phy problems, so I focused on that.
> HSR says it is exactly same programming sequence as SM8650
> and such was used.
> 
> Just note, that we have ADSP remoteproc up, but no audio including USB mux,

Are you talking about wcd939x-mux?

If so, you need that or the lanes won't be properly connected

Konrad

Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[Krzysztof Kozlowski]

On 31/03/2026 17:03, Konrad Dybcio wrote:
> On 3/31/26 5:01 PM, Krzysztof Kozlowski wrote:
>> On 31/03/2026 16:49, Konrad Dybcio wrote:
>>> On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
>>>> Dependency
>>>> ==========
>>>> Depends on USB patches, which are being reviewed, therefore marking it
>>>> as RFC as it cannot be applied.
>>>> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>>>>
>>>> Unmerged bindings used here
>>>> ===========================
>>>> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
>>>> (DRM MDSS bindings were applied)
>>>>
>>>> Description
>>>> ===========
>>>> I did not enable DisplayPort because it does not work on my board and I
>>>> don't know why. I double checked QMP combo phy and other bits, and
>>>> everything is looking fine, but still no USB display, so maybe I miss
>>>> some other dependencies as this is early upstream.
>>>
>>> What was the furthest that you got? We can certainly try to help..
>>>
>>> Got USB Type-C mode mux events?
>>> PHY initialized and configured to 2/4-lane DP mode?
>>> Are the AUX transfers failling?
>>
>> [   43.975329] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
>> [   43.975410] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
>> [   45.780383] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
>> [   45.780463] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
>> [   45.780521] msm_dpu ae01000.display-controller: [drm:msm_dp_pm_runtime_suspend] type=10 core_init=1 phy_init=1
>>
>> pastebin: https://pastebin.com/BVXy3Qeq
>>
>> Abel pointed me to the phy problems, so I focused on that.
>> HSR says it is exactly same programming sequence as SM8650
>> and such was used.
>>
>> Just note, that we have ADSP remoteproc up, but no audio including USB mux,
> 
> Are you talking about wcd939x-mux?

Yes

> 
> If so, you need that or the lanes won't be properly connected

Ha! That would explain, although I had impression that with disabled
WCD939x mux the SM8750 DP still works.

Well, I don't have that WCD939x and it is left for other team to finish
a bit later, so we can leave the USB DP for now. I will re-visit that
when audio progresses.

Best regards,
Krzysztof

Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[Konrad Dybcio]

On 3/31/26 5:06 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 17:03, Konrad Dybcio wrote:
>> On 3/31/26 5:01 PM, Krzysztof Kozlowski wrote:
>>> On 31/03/2026 16:49, Konrad Dybcio wrote:
>>>> On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
>>>>> Dependency
>>>>> ==========
>>>>> Depends on USB patches, which are being reviewed, therefore marking it
>>>>> as RFC as it cannot be applied.
>>>>> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>>>>>
>>>>> Unmerged bindings used here
>>>>> ===========================
>>>>> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
>>>>> (DRM MDSS bindings were applied)
>>>>>
>>>>> Description
>>>>> ===========
>>>>> I did not enable DisplayPort because it does not work on my board and I
>>>>> don't know why. I double checked QMP combo phy and other bits, and
>>>>> everything is looking fine, but still no USB display, so maybe I miss
>>>>> some other dependencies as this is early upstream.
>>>>
>>>> What was the furthest that you got? We can certainly try to help..
>>>>
>>>> Got USB Type-C mode mux events?
>>>> PHY initialized and configured to 2/4-lane DP mode?
>>>> Are the AUX transfers failling?
>>>
>>> [   43.975329] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
>>> [   43.975410] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
>>> [   45.780383] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
>>> [   45.780463] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
>>> [   45.780521] msm_dpu ae01000.display-controller: [drm:msm_dp_pm_runtime_suspend] type=10 core_init=1 phy_init=1
>>>
>>> pastebin: https://pastebin.com/BVXy3Qeq
>>>
>>> Abel pointed me to the phy problems, so I focused on that.
>>> HSR says it is exactly same programming sequence as SM8650
>>> and such was used.
>>>
>>> Just note, that we have ADSP remoteproc up, but no audio including USB mux,
>>
>> Are you talking about wcd939x-mux?
> 
> Yes
> 
>>
>> If so, you need that or the lanes won't be properly connected
> 
> Ha! That would explain, although I had impression that with disabled
> WCD939x mux the SM8750 DP still works.

I don't know what's the power-on-reset setup, but there is a nonzero
chance that if your recollections are correct, flipping the cable may
make it work. But that'd be pure luck.

> Well, I don't have that WCD939x and it is left for other team to finish
> a bit later, so we can leave the USB DP for now. I will re-visit that
> when audio progresses.

But.. can't you just copy-paste the sm8750-mtp node and fix up the reset
pin?

Konrad

Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display

[Krzysztof Kozlowski]

On 31/03/2026 17:23, Konrad Dybcio wrote:
>>> If so, you need that or the lanes won't be properly connected
>>
>> Ha! That would explain, although I had impression that with disabled
>> WCD939x mux the SM8750 DP still works.
> 
> I don't know what's the power-on-reset setup, but there is a nonzero
> chance that if your recollections are correct, flipping the cable may
> make it work. But that'd be pure luck.
> 
>> Well, I don't have that WCD939x and it is left for other team to finish
>> a bit later, so we can leave the USB DP for now. I will re-visit that
>> when audio progresses.
> 
> But.. can't you just copy-paste the sm8750-mtp node and fix up the reset
> pin?

I just wanted to avoid doing concurrent work, but sure, I can try. I'll
test it before sending v2.

Best regards,
Krzysztof