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

[Jianfeng Liu <liujianfeng1994@gmail.com>]

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:

  - 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