00:11 <DavidHeidelberg> konradybcio: is possible that "drm/msm/dsi: Enable runtime PM" could cause https://gitlab.freedesktop.org/mesa/mesa/-/jobs/54903055 ?

00:15 <DavidHeidelberg> bumped from 6.6.13 to 6.6.16 and it seems this commit got backported, thou it will probably cause some issues, I'll try to retest with reverted commit

00:17 <flamingradian[m]> a series was split when the first patch was backported

00:33 <DavidHeidelberg> konradybcio: ok, it's probably not this one :( time to seriously bisect

08:54 <lumag> DavidHeidelberg, Initially I had issues with that commit too, it triggered sdm845 CI issues. But at the next cycle it worked fine.

08:55 <lumag> Maybe there is some other issue which gets triggered by it

08:56 <lumag> DavidHeidelberg, https://lore.kernel.org/dri-devel/3b4865d7-2730-1ea9-d75b-a015d27aa84d@linaro.org/

08:57 <lumag> DavidHeidelberg, It might be that it needs something like 4b6ea15c0a1122422b44bf6c47a3c22fc8d46777

12:09 <krzk> z3ntu: just implement my last comment in the email...

12:09 <krzk> you cannot drop existing compatible from a driver.

12:16 <z3ntu> krzk: I'm not dropping the compatible from the driver in that patch though? I'm keeping it around explicitly to allow older dtbs to work

12:19 <z3ntu> krzk: but at the same time there's no generic configuration for hfpll that works for all SoCs so that's why I added qcs404-hfpll there so that newer dt's can use that so there's no one thinking "qcom,hfpll" works for more SocS

12:23 <krzk> z3ntu: but you asked me here if it can be dropped..

12:23 <krzk> "So just have e.g. "qcom,qcs404-hfpll" in driver+bindings+dts?"

12:28 <z3ntu> krzk In driver I'd keep qcom,hfpll for compatibility. But for bindings (+dts) is just qcom,qcs404-hfpll the way to go? Or do "qcom,qcs404-hfpll", "qcom,hfpll"?

12:32 <krzk> z3ntu: I don't know what you want to achieve and how is the hardware being discussed.

12:32 <krzk> Maybe first present how and what this hardware should be used, or what is wrong with existing binding, and you will get specific answer to that

12:34 <z3ntu> krzk: My initial goal was only sending conversion to yaml but I noticed "qcom,hfpll" was only used for qcs404 and msm8974 (patches coming later) needs a different config so I thought I'd be a good idea to make the current qcs404 config in the driver into its own compatible and stop using this pseudo generic qcom,hfpll compatible

12:35 <DavidHeidelberg> lumag: I reverted only the Enable rt PM commit and it didn't helped, but I didn't reverted the second one. Also I bisected to v6.6.13..v6.6.14 so it could be the second commit causing it

13:04 <ungeskriptet> Why does simple-framebuffer no longer work on SM8450 and onwards? Is the bootloader disabling it?

15:06 <DavidHeidelberg> lumag: I tried to fix it similarly to 4b6ea15c0a1122422b44bf6c47a3c22fc8d46777, no help, reverting both patches helped

15:06 <DavidHeidelberg> konradybcio: ^

15:45 <DavidHeidelberg> btw. same issue is present in 6.8-rcX

16:28 <JIaxyga[m]> <ungeskriptet> "Why does simple-framebuffer no..." <- konradybcio: btw yes

16:28 <JIaxyga[m]> have you tested panel on xperia-nagara?

16:28 <DavidHeidelberg> lumag: last thing: can you do https://www.spinics.net/lists/linux-arm-msm/msg188455.html locally or should I run it on CI (more annoying, but can do :D )

16:33 <DavidHeidelberg> I can confirm that reverting offending patch fixed the issue on 6.8-rc3

16:34 <DavidHeidelberg> oops, nope, a bit of log ahead, but it still failed

20:03 <lumag> DavidHeidelberg, I will do it locally. I started investigating apq8096, but didn't finish it.