arch/arm64/boot/dts/qcom/eliza-mtp.dts | 63 +++++ arch/arm64/boot/dts/qcom/eliza.dtsi | 433 +++++++++++++++++++++++++++++++++ 2 files changed, 496 insertions(+)
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>
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.