07:45 <jackm[m]> <aka_[m]> "i don't understand question...." <- > <@aka_:matrix.org> i don't understand question.... (full message at <https://matrix.org/oftc/media/v1/media/download/AeOk9fq5j3915u-W8aCr1AKUHufQJ8rODOnnPCvbh8hb1aV_rHfGtWMc0dPwBVlCNI6cvSazUPDExSIKa6cN43RCeWw3RNbwAG1hdHJpeC5vcmcvVVN1cFpRblpqdEpLb0RFaEVXZVRhVEhm>)

09:43 <krzk> lumag: does saving pll state during init (probe) make sense? https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c?h=next-20250424#n812 this is causing ...

09:43 <krzk> lumag: that driver thinks state is saved and then on first phy enable sets PLL (VCO) clock to 0

09:44 <krzk> lumag: which causes the pll lock failures... for which I used your workaround from patchwork (https://patchwork.freedesktop.org/patch/542000/?series=119177&rev=1)

10:00 <krzk> when I comment out that initial save state, I got rid of DSI PLL lock failures even without your patch from patchwork

10:04 <krzk> huh... this looks like solving all my damn problems :) I will send a RFC code/patch in our email thread

16:23 <lumag> krzk, it definitely did make sense when we were not resetting the MDSS. It ensured that the display continues to work with the bootloader-programmed settings and mode

16:24 <lumag> Nowadays it should also make sense: the CCF reads those values and expects that they are preserved across MDSS collapse

16:25 <lumag> so, if the display is enabled by the bootloader and you don't store the state, the CCF will read the divisors (and assume they stay programmed to the HW), but the MDSS GDSC power collapse would cause them to be dropped to default state (to the surprise of CCF).

19:08 <krzk> lumag: Thanks, that piece of code is also causing problems for sm8750, because all register after the collapse are 0, so VCO is set to 0 and this is what is later programmed in restore state.

19:08 <krzk> I have some sort of solution for that and most of my problems, although I still need to set rate on pixel/byte clocks while DSI PLL is prepared - otherwise RCG did not update their state (just like reparenting)

19:09 <krzk> The problem is that downstream does not have such cod or at least no such difference against sm8650.

19:10 <krzk> So I think that upstream driver has some other issues which were just not visible so far (like that recalc/set_rate while DSI PLL is shutdown, which I mentioned in email)