Re: [PATCH] clk: qcom: dispcc-x1e80100: don't disable display PLLs in the unused-clock sweep

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

On 10/3/26 4:02 PM, Jianfeng Liu wrote:
> Hi Konrad,
> 
> Thanks for the pointer! I gave Brian's series [1] a shot on a
> 7.3-rc4 based tree with my pll0 patch reverted (the trivial
> conflict in the pmdomain hunk resolved by hand), and on this
> platform it does not solve the issue - it actually makes things
> worse.
> 
> With the series applied, the unused-clock sweeps for the display
> providers fire at 1.4-1.5s, which lands *inside* the display
> bring-up sequence instead of before it:
> 
>     [    1.381597] tcsrcc-x1e80100 1fc0000.clock-controller: clk: Disabling unused clocks
>     [    1.468038] qcom-edp-phy aec5a00.phy: clk: Disabling unused clocks
>     [    1.468194] dispcc-x1e80100 af00000.clock-controller: clk: Disabling unused clocks
>     [    1.807670] msm_dpu ae01000.display-controller: bound ae90000.displayport-controller (ops msm_dp_display_comp_ops [msm])
>     [    1.808271] msm_dpu ae01000.display-controller: bound aea0000.displayport-controller (ops msm_dp_display_comp_ops [msm])
>     [    1.810010] msm_dpu ae01000.display-controller: bound ae9a000.displayport-controller (ops msm_dp_display_comp_ops [msm])
>     [    1.860460] [drm:dpu_kms_hw_init:1168] dpu hardware revision:0x90020000
>     [    2.002334] msm_dpu ae01000.display-controller: [drm] fb0: msmdrmfb frame buffer device
> 
> The reason is that the mdss device's probe returns early; the
> actual display bring-up happens later through the component
> framework (controllers binding at 1.8s, first modeset after
> that). The driver core only sees "probed", so sync_state fires
> before any of the display clocks have been claimed:

Oh hmm.. perhaps fw_devlink doesn't handle that case..
+Dmitry do you think we can make it?

Konrad

> 
>   - tcsrcc's sweep at 1.381s disables tcsr_edp_clkref_en while
>     the eDP PHY is still mid-probe (the PHY is about to claim it
>     as its "ref" clock)
>   - the eDP PHY provider's own sweep at 1.468s disables its
>     link/pixel output clocks
>   - dispcc's sweep at 1.468s disables all of
>     disp_cc_mdss_dptx3_{aux,link,pixel0}*, whose consumer (the
>     DP controller) only binds at 1.8s
>   - disp_cc_pll0 is still swept at 1.468s, so the reset-relock
>     lottery from my patch's commit message remains as well
> 
> The outcome is again a ~50% per-boot lottery, just with a
> different and harsher failure mode. In 2 out of 4 boots the eDP
> panel came up broken: the top third of the screen shows fine
> green/black striping and the lower two thirds stay black. On
> the broken boots the final clk_summary shows the whole eDP link
> clock chain disabled and unclaimed (disp_cc_mdss_dptx3_{aux,
> link,pixel0}*, tcsr_edp_clkref_en, and even the eDP PHY's own
> link/vco_div clocks), i.e. the bring-up failed right where the
> sweeps had just fired. On the good boots the same clocks are all
> claimed and enabled. The per-boot variable is simply whether the
> sweeps at 1.38-1.47s happen to land before or after the DP
> controller and the PHY claim their clocks.
> 
> So for this class of problems - firmware handover state, where
> the hardware consumes clocks that the CCF does not know about
> yet, and whose drivers enable them later than probe() - sync_state
> trades the old race for a new one: the trigger ("all consumers
> probed") still precedes the moment the clocks actually get
> enabled, and the decision (enable_count == 0) still cannot see
> the firmware-provided state. The original relock lottery remains
> as well, since disp_cc_pll0 is still swept at 1.468s, before
> mdp_clk is first enabled at ~1.86s.
> 
> I do think the series is valuable for the module / late-probe
> cases it targets, and I'm happy to help testing it further. But
> the pll0 fix still seems needed, not least because it can be
> backported to stable branches while the sync_state work lands.
> 
> Full dmesg and clk_summary captures from both the good and broken
> boots are available on request.
> 
> [1] https://lore.kernel.org/linux-arm-msm/20260626-clk-sync-state-v1-0-4156d8196dc8@redhat.com/
> 
> Jianfeng