07:11 <aka_[m]> Marijn: maybe i will try rc3 too, I wonder if it's maybe fault of panel IC it ships with Nt36672a in theory after reset it shouldn't kill supplies.

07:11 <aka_[m]> I also noticed once I progress booting to rootfs display goes On and off like 8 times

07:20 <aka_[m]> Or I will try to just get rest of hardware and keep fb console for a while

07:20 <Marijn[m]> aka _: Can you try reverting drm/msm to 5.18? https://github.com/SoMainline/linux/commit/46f8758ea83c2f58e37184526baebe1d5a379e97

07:21 <aka_[m]> Gonna try that

07:25 <Marijn[m]> aka_: thanks, let me know if that works! If it does I'm more confident our issue is shared and will need some digging as to why (or pray it's fixed on -next, but then something needs to be ported to stable...)

13:05 <Marijn[m]> lumag_: Before I go looking around various gits - do you happen to have a DPU configuration for sm8450 up somewhere?

13:05 <Marijn[m]> I have more hardware to test DSC on 😬

14:27 <Tooniis[m]> lumag_: did your power sequencing patches for qca get anywhere? or did you take a different approach later?

14:41 <konradybcio> bump, having wifi would be nice

15:01 <konradybcio> simplefb is dead since at least 5.19-rc3, dpu doesn't even bother trying to probe on -next-20220714

15:01 <konradybcio> adding fw_devlink=off gives me simplefb back.. ..for the 0.4 seconds before the platform hangs and kills itself in pain

15:02 <konradybcio> this happens on at least 8250

15:19 <aka_[m]> Marijn: I have reverted to rc3 and it still shows same error

15:19 <aka_[m]> havent reverted with your commit yet,(its just too big and fails a lot here)

15:21 <aka_[m]> just gonna grab branch and put my stuff on top

15:21 <aka_[m]> should be faster

15:54 <aka_[m]> ok with ninges kernel it doesnt even probe

16:09 <aka_[m]> display stay same like it was nothing takes over it

16:18 <aka_[m]> devices_deferred empty obv

16:21 <Marijn[m]> <aka_[m]> "havent reverted with your commit..." <- Ouch I gave it to you in hopes of simplifying the whole ordeal

16:21 <aka_[m]> i think even with 5.18 it might not work

16:22 <aka_[m]> there was an issue on 8953 and some bridge

16:22 <aka_[m]> some parade thing which seems got sorted in -next

16:59 <aka_[m]> on rc1 there is no error but also no picture too

17:35 <aka_[m]> Marijn: in theory it seems i no longer have this error on latest rc from torvalds/master

17:40 <aka_[m]> before it was only alocated by fbcon

17:40 <aka_[m]> now phoc can be found

17:42 <aka_[m]> https://pastebin.com/s19bfUdR

17:42 <aka_[m]> bit sad log

18:08 <aka_[m]> my bad it still is there but i was unable to get to top of that log

18:29 <aka_[m]> uh modprobe -r panel reboots device

18:29 <aka_[m]> lol

18:29 <aka_[m]> Marijn: building panel as module kinda gets rid of that error....

18:29 <aka_[m]> msm_dpu 5e01000.mdp: bound 5e94000.dsi (ops dsi_ops)

22:57 <Marijn[m]> lumag_: I'm currently also working on bringing up display on an sm8250 device before sending DSC patches, for validation. Unfortunately it behaves much different, starting with MDSS not probing on -next as of today. Unlike sdm845 I have to run `echo ae00000.mdss > /sys/bus/platform/drivers/msm-mdss/bind` to make it probe. Any idea what's up, before I start debugging?

22:58 <Marijn[m]> (I think it does the same on 5.19 rc's and before, only konradybcio has played with this yet and got exactly as far iirc)

22:59 <bamse> Marijn[m]: have you tried fw_devlink=permissive ?

22:59 <Marijn[m]> bamse: Unfortunately I also had to revert https://lore.kernel.org/all/20220426212136.1543984-1-bjorn.andersson@linaro.org/ to circumvent `disp_cc_mdss_mdp_clk_src: RCG did not turn on` + `disp_cc_mdss_ahb_clk status stuck at 'off'` :/

22:59 <Marijn[m]> bamse: I've only tried fw_devlink=off

23:01 <bamse> Marijn[m]: i don't think you should do "off"...as that will make sure that devlinks needed for runtime power management are also disabled

23:03 <Marijn[m]> bamse: I just noticed I enabled `CONFIG_CMDLINE_FORCE` recently to fix another device, and that obviously prevents cmdline parameters from `mkbootimg` (through the BL) from ending up in the kernel

23:04 <Marijn[m]> Now with proper testing, both off and permissive don't boot at all

23:40 <Marijn[m]> lumag_: One more code-design question before I leave (it's way past bedtime here): when a DSC config is available (assigned by the panel), `dpu_encoder_get_topology` unconditionally hardcodes 2 DSC blocks which are allocated on the resource manager. `dpu_rm_get_assigned_resources` returns 2 blks, but the pointers are NULL when not assigning any DSC blocks in hw_catalog, resulting in nullptr dereferences further down the line. Don't you

23:41 <Marijn[m]> think this should error gracefully instead of segfaulting, or is that "okay" when hw_catalog is "wrong"?

23:41 <Marijn[m]> Don't worry I'll submit those additions with the rest of the DSC patchseries I'm preparing, by the way ;)