On Thu, Sep 24, 2026 at 03:36:05PM +0200, Luca Weiss wrote:
> Hi Dmitry,
>
> On Thu Sep 24, 2026 at 2:51 AM CEST, Dmitry Baryshkov wrote:
> > dsi_pll_7nm_vco_prepare() de-asserts PLL_SHUTDOWNB and starts the PLL,
> > but leaves the PHY digital top powered down; only dsi_7nm_phy_enable()
> > sets DIGTOP_PWRDN_B. The PLL cannot lock in that state. This went
> > unnoticed for as long as the PLL was only ever prepared from the DSI
> > host's enable path, after the PHY had been enabled.
> >
> > Since commit acf7a91d0b0e ("clk: qcom: dispcc-sm8250: Enable parents for
> > pixel clocks") the clock framework enables the PHY PLL on its own while
> > applying the DT's assigned-clock-parents from of_clk_set_defaults(), at
> > probe time, before the PHY has been touched. The lock fails, the failed
> > enable leaves the pixel clock with an unbalanced enable count, and the
> > retries on every probe attempt stall the boot for tens of seconds:
> >
> > DSI PLL(0) lock failed, status=0x00000000
> > PLL(0) lock failed
> > dsi0_phy_pll_out_dsiclk already disabled
> > WARNING: drivers/clk/clk.c:1188 at clk_core_disable+0x244/0x24c
> > clk_core_disable
> > __clk_set_parent_after
> > clk_core_set_parent_nolock
> > clk_set_parent
> > of_clk_set_defaults
> > platform_probe
> >
> > CMN_CTRL_0 reads 0x20 at the failing attempt: PLL_SHUTDOWNB set,
> > DIGTOP_PWRDN_B clear. Setting DIGTOP_PWRDN_B alone makes the same PLL
> > lock, with no rate change and no other register touched.
> >
> > Power up the digital top together with the PLL bias, and power it down
> > again with it. The normal enable path is unaffected: dsi_7nm_phy_enable()
> > holds the bias reference and writes CMN_CTRL_0 in full anyway.
>
> FWIW the same fix seems to help on the 10nm with this error on bootup
>
> [ 0.503085] msm_dsi_phy ae94400.phy: [drm:dsi_pll_10nm_vco_prepare]
> *ERROR* DSI PLL(0) lock failed, status=0x00000000
> [ 0.503168] msm_dsi_phy ae94400.phy: [drm:dsi_pll_10nm_vco_prepare]
> *ERROR* PLL(0) lock failed
>
> I've also ported more commits from 7nm to 10nm locally, will send them
> soon, since anyway they should be good fixes and code quality
> improvements
>
> drm/msm/dsi_phy_10nm: Protect PHY_CMN_CLK_CFG0 updated from driver side
> drm/msm/dsi_phy_10nm: Protect PHY_CMN_CLK_CFG1 against clock driver
> drm/msm/dsi_phy_10nm: Do not overwite PHY_CMN_CLK_CFG1 when choosing bitclk
> source
> drm/msm/dsi_phy_10nm: Define PHY_CMN_CLK_CFG[01] bitfields and simplify saving
> drm/msm/dsi_phy_10nm: Define PHY_CMN_CTRL_0 bitfields
> drm/msm/dsi_phy_10nm: Fix reading zero as PLL rates when unprepared
>
> Unfortunately some other warnings/errors still persist on bootup that I
> can't figure out... maybe you have some idea?
>
> If not, I don't want to bring this thread too much offtopic :)
>
> [ 1.197104] ------------[ cut here ]------------
> [ 1.197113] dsi0_pll_bit_clk: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not
> set
This looks like the read from the unpowered PLL block. Check that all
required bits are set. It might be worth replacing this standard
clk_divider (and the one in 7nm) with the special version that doesn't
go to the registers if the PHY is unpowered.
> [ 1.197134] WARNING: drivers/clk/clk-divider.c:145 at
> divider_recalc_rate+0xac/0xd4, CPU#0: kworker/u32:0/12
> [ 1.197150] Modules linked in:
> [ 1.197160] CPU: 0 UID: 0 PID: 12 Comm: kworker/u32:0 Not tainted
> 7.2.0-00088-gddc402c24fff #86 PREEMPTLAZY
--
With best wishes
Dmitry
