Re: [PATCH 0/2] driver core: platform: / drm/msm: dp: Delay applying clock defaults

[Jens Glathe]

Hi there,

On 14.08.25 11:18, Stephan Gerhold wrote:
> Currently, the platform driver core always calls of_clk_set_defaults()
> before calling the driver probe() function. This will apply any
> "assigned-clock-parents" and "assigned-clock-rates" specified in the device
> tree. However, in some situations, these defaults cannot be safely applied
> before the driver has performed some early initialization. Otherwise, the
> clock operations might fail or the device could malfunction.
>
> This is the case for the DP/DSI controller on some Qualcomm platforms. We
> use assigned-clock-parents there to bind the DP/DSI link clocks to the PHY,
> but this fails if the PHY is not already powered on. We often bypass this
> problem because the boot firmware already sets up the correct clock parent,
> but this is not always the case.

I have this case on the Lenovo Ideapad Slim5x 14Q8X9, on the HDMI port. 
when booted without an active HDMI connected device and hotplugged 
later, it produces these errors (and no display):


[  552.501910] [drm:dpu_encoder_phys_vid_wait_for_commit_done:545] [dpu 
error]vblank timeout: 2021300
[  552.501927] [drm:dpu_kms_wait_for_commit_done:527] [dpu error]wait 
for commit done returned -110
[  552.540863] [drm:dpu_encoder_frame_done_timeout:2731] [dpu 
error]enc40 frame done timeout

When cold-plugged this works, and can be hot-plugged later.

Further investigation showed that the main link clock doesn't come up 
regardless of what is done, unless it was initialized by the boot 
firmware before. Applying this series (found by Val, thanks again) 
solved this issue.

Tested-by: Jens Glathe <jens.glathe@xxxxxxxxxxxxxxxxxxxxxx>

> [...]

with best regards

Jens