05:14 <DylanVanAssche> bamse: hmmmm few days ago I could make it work by switching PDC profiles. However, after a bootloop I reflashed Android and back postmarketOS. Since then that workaround doesn't help anymore.

05:14 <DylanVanAssche> bamse: To me, it sounds like an EFS thing?

05:15 <bamse> could be...

05:21 <DylanVanAssche> bamse: will try to dump the EFS of a working and non working one. Will need to figure out how to do that on Linux, most guides are for Windows

10:07 <narmstrong> Marijn[m]: Hi ! I'm enabling DSI/DSC support om SM8550 and I was wondering which platform/panel you made work, and what was is the topology (LM, PP, DSC, INTF counts) that are reported to work

10:09 <narmstrong> the panel I'm trying to use has a splice widths on half the panel width and needs the DSC merge mode, but tit looks like this topology is not entirely supported upstream, or not on new HW

10:10 <Marijn[m]> Hi Neil! We made it work on sdm845, and I have only gotten started on sm8[12]50, have you seen the patch series that I sent last week?

10:11 <narmstrong> Marijn[m]: yes I used them since the dsc_bind_pingpong_blk is also needed for DSC 1.2 HW

10:11 <Marijn[m]> All my devices use the DSCMERGE topology, so same as yours

10:11 <Marijn[m]> However, sm8550 (and 8[34]50?) use DSC 1.2 which is not yet implemented

10:11 <Marijn[m]> (Or rather, I have not investigated how much difference there is)

10:12 <narmstrong> there's a big difference but the downstream code is easily portable

10:12 <narmstrong> Marijn[m]: so you got a fuzzy output with DSC merge mode ? or a black screen ?

10:12 <Marijn[m]> narmstrong: I was also told by abhinav__ that you are using a cmdmode panel now? That needs additional features as well which I hope to submit really really soon - but it should not be a requirement for DSC as long as you accept odd framerates and tearing

10:13 <narmstrong> Marijn[m]: nop I'm trying to enable the video mode right now since the panel supports both, it seems easier

10:13 <Marijn[m]> narmstrong: both, really. Initially we had corruption and only saw the top-most block being updated on the panel, and now after lots of rebases and changes the screen is black - have not yet investigated what happened

10:15 <Marijn[m]> That's what I/we get for supporting and actively developing 10+ devices on the same branch :)

10:15 <narmstrong> yep it's part of the risks!

10:17 <narmstrong> Marijn[m]: do you have an old known-to-barely-work tree somewhere ? if a recent commit broke dsc merge it could be interesting to figure that out

10:45 <Marijn[m]> narmstrong: that was going to be my next step, compare with before a rebase and see if any of my dpu/panel or other unrelated changes affected anything

10:46 <Marijn[m]> Not publicly but I do take snapshots of branches every once in a while and the version where the screen flickers with corrupted data my be on there

10:48 <Marijn[m]> narmstrong: what is your timeframe for working on DSC? I cannot do anything today nor in the evening, but can start looking and helping tomorrow

10:51 <narmstrong> Marijn[m]: I’m full time on this, any hint would help! But registers looks fine for me but since I don’t have a long experience with dpu it may have missed an important setting

10:55 <Marijn[m]> Lovely! I'm also stuck at "registers match, why is the output still corrupted" on 8[12]50

10:56 <Marijn[m]> My next quest was looking more into dsi host, clocks and panel dcs, maybe something is wrong there

10:57 <Marijn[m]> I'll do my best to clean up a branch and share it with you, including the patches sent thus far and a panel driver... But I'm a bit distracted getting the INTF TE changes in abhinav__'s hands too :)

11:00 <Marijn[m]> narmstrong: you may be able to scavenge something from https://github.com/SoMainline/linux/commits/marijn/longbois-next but it doesn't include all changes

11:00 <Marijn[m]> Most/all dsc code is there though

12:26 <narmstrong> Marijn[m]: thx for the tree, I'll definitely scavenge into it

12:27 <narmstrong> Marijn[m]: are you doing the INTF TE changes? with it it could be possible to try CMD mode DSC then

12:51 <Marijn[m]> narmstrong: already tried that. Intf te solves all our issues on non-dsc, but doesn't solve anything for DSC panels

12:52 <narmstrong> ok thx

16:25 <Marijn[m]> narmstrong: and did you manage to make any progress / discoveries that I could try out later today?

16:43 <narmstrong> Marijn[m]: so far no

16:54 <Marijn[m]> narmstrong: that's unfortunate, I'm thinking of diffing with downstream registers and an older branch again to see if there has been any unexpected change. At least managed to utilize a train ride to clean up INTF TE patches a little, which I really want to get off my hands first

16:54 <Marijn[m]> Will keep you posted regardless

16:56 <narmstrong> Marijn[m]: yup I Hope you’ll find something before me :-p I’ll also diff the downstream registers aswell

17:32 <abhinav__> narmstrong are you implementing DSC 1.2? We were doing that for adding support for DSC over DP

17:32 <abhinav__> like we mentioned during our last call

17:34 <narmstrong> abhinav__: yes i took the downstream implementation while you finish the upstream version but I probably missed some stuff for the 1.2 integration in the rest of the dpu1 driver

22:41 <Marijn[m]> abhinav__: Does DP use the same DSC block for performing compression? I guess so since after sdm845, where a crossbar was added to connect the DSC block to any CTL/PP? Have you found anything interesting that is worth sharin?

22:41 <Marijn[m]> And abhinav__ lumag since both of you replied to the DSC patches, and about a week has passed, time is probably ripe to prepare and send a V2 so that you can build on top of that :)

22:43 <Marijn[m]> narmstrong just making sure I processed your initial message correctly: you mentioned something about half slice width and this not being fully implemented properly; do you have any ideas/pointers/guesses as to what that could be that you're missing? For completeness also my sdm845 panel uses a slice width of half the panel in DSCMERGE and it's totally happy, so it's a "new" SoC thing :/

23:14 <abhinav__> Marijn[m] yes they use the same DSC block. So we have several instances of the DSC block as you must have seen in the hardware catalog. Each of those DSC blocks can work either with DSI or DP or eDP

23:15 <abhinav__> I have not yet figured out what could be wrong. Lets use a gitlab issue to track this effort