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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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