<konradybcio>
as for the gpu, 8996 and 8 should (?) take a cpr reference, at least 8996
<konradybcio>
i added mx as a half-measure to provide at least some more stability
<konradybcio>
but then the 8996 patch for that never landed
<strongtz[m]>
<strongtz[m]> "If pcie is disabled, xhci and..." <- regarding suspend on sm8550, I tried again just now. It doesn't crash in both s2idle and deep anymore, and the screen can light up.
<konradybcio>
yeah uh theres too much fluff to reasonably go through it
<konradybcio>
please retest on next with perhaps the most important additions only
<strongtz[m]>
makes total sense, will try
<strongtz[m]>
with a much more simplified branch below, I can only see pcie_0_gdsc status stuck at 'off' in the resume process, then the device crashes
<calebccff>
there is this mdss-dsi-post-on-backlight command sequence which is probably important but adding it doesn't help
<lumag>
calebccff, yes, it's a proprietary stuff.
<lumag>
The packet that starts with 39 01 00 00 00 00 81 9E is PPS
<calebccff>
it's configured as single DSI but with two layer mixers, does mainline need any special handling for that? I'm not sure how the topology is determined
<calebccff>
welp, funn
<lumag>
No, there is no need for special handling for 2 LMs
<lumag>
For the reference, here is the PPS packet from Pix3:
<lumag>
(contents, of course, without the wrapping):
<Marijn[m]>
Because it's not at all working. There's a drm/msm issue floating around showing the current status of things
<Marijn[m]>
Every 6th DSC slice renders correctly, and the right half is not functioning
<Marijn[m]>
Qcom engineers checked the registers and they say it looks alright, so it might be clocks or DSI DCS that I'm sending. Just the sample size of 1 makes this hard to debug
<Marijn[m]>
By the way when looking at the PPS, make sure to include or exclude the header depending on how you look at it. I've seen that got messed up more times than expected :)
<calebccff>
haha oh yeah for sure
<calebccff>
im doing __builtin_dump_struct() for sanity checking
<lumag>
Marijn[m], With Pix3 I ended up wiring up debug prints to all DSI writes and to all DSI transfers on downstream kernel.
<lumag>
maybe I should do the same with the RB5 / 4k mode.
<lumag>
But nobody at QC was able to promise me that RB5/4k has ever been tested.
<lumag>
And I don't have phones with dual-DSI-and-DSC
<lumag>
calebccff, I usually do print_hex_dump or print_hex_dump_bytes()
<calebccff>
lumag: yeah doing that do... forgot to #define DEBUG :(
<calebccff>
to*
<Marijn[m]>
lumag: yeah, I should do that
<Marijn[m]>
And did that for some critical writes already, to not get spammed. Their values were all equal
<Marijn[m]>
Not to forget this was on one of the "VM" SoCs, where half the code is `if (sde->something_are_we_running_in_a_vm) return;` so it doesn't even send half the regular DSI DCS for example
<lumag>
Well, that means that we can skip that too
<lumag>
But note that you have to get past the 'splash screen' handover
<Marijn[m]>
Yeah, it was in Android UI
<Marijn[m]>
Anyway, figuring out what to skip is a hassle
<lumag>
Ah, just Linux kernel + modetest, that was enough
<lumag>
Especially because w/o fbcon the panel gets restarted each time.
<Marijn[m]>
But for example PPS was skipped, making it harder to compare per the above
<Marijn[m]>
Setting that downstream kernel up like such is probably a bigger hassle than just booting into its original OS, while only modifying the kernel a bit
<lumag>
Hmm, worked mostly like a charm :D
<lumag>
But it was 4.9
<Marijn[m]>
This was 5.4 or 5.10
<calebccff>
so the good news is the downstream PPS matches my generated one exactly
<lumag>
calebccff, that's good already
<calebccff>
bad news is now i have no idea why it's not working XD
<lumag>
I'd say, if the panel stays black, you have issues with backlight