07:11 <Marijn[m]> Tooniis: -22 during initialize likely means the DSI host is off, but you probably figured that from an earlier message in this thread (`panel.prepare_prev_first = true;`)

07:14 <Marijn[m]> JIaxyga: since you are on a _video mode_ panel with DSC, there were some mumblings previously about arbitrary `if (video mode) dont;` clauses in DSC codepaths, because they have not been tested. We should probably remove those and/or see if more code (typically register writes) need to be implemented before it starts to work

07:16 <Marijn[m]> For example, there's nothing in phys_vid.c about DSC except getting the block mask... I'd say this affects the timings calculated there too

07:17 <JIaxyga[m]> Marijn[m]: Sadly

07:17 <JIaxyga[m]> I can test at any time if there are any fixes

07:17 <Marijn[m]> OTOH phys_cmd.c doesn't have much either, it's all in the generic codepath it seems

07:28 <krzk> lumag: Marijn[m]: what do you mean that https://lore.kernel.org/all/5w2hvzmwzqm4ffopzewveaviebq2ig7awimeo6ipcehx5a43ae@mlwffkf2ctn5/ it was fixed? The next since few days has it still broken, so why fixed code was applied somewhere but did not get into next?

07:29 <lumag> krzk, because Marijn[m] has sent an updated version, but I did not pick it up yet.

07:29 <lumag> I'll attend to it either today or in a next couple of days.

07:30 <krzk> but that is not how next is working...

07:30 <Marijn[m]> Anyway, as mentioned yesterday that `qcom,mdss-dsc-encoders = <1>` in your DTS seems to indicate a non-DSCmerge topology. I am not sure if that could affect the datastream (would at the very least see corruption I think, but the kernel says this is a "power optimal" topology as if it should be compatible), but we could try implementing it

07:31 <Marijn[m]> JIaxyga: it shouldn't be much more complicated than changing a few `num_dsc = 2` and `num_lm = 2` to `1

07:31 <lumag> krzk, we don't have a non-rebasing guarantee in linux-next.

07:32 <krzk> lumag: that's ok, but why pushing to next something incomplete which triggers warnings/issues and then not allowing to fix it (because it was fixed but not pushed to next)?

07:33 <krzk> How one can work on next in such case?

07:34 <Marijn[m]> You are allowed to push fixes... But in this case another fix (a replacement of the original patch...) was sent much in advance and will take precedence

07:34 <krzk> sure, but then it should replace the next material some days ago, not in few days from now on

07:36 <krzk> otherwise next is just some outdated snapshot

07:36 <krzk> Imagine now every maintainer does like this - keeps old stuff in next and some new version of existing patches coming in queue, bu tnot yet merged or pushed...

07:36 <krzk> Imagine Bjorn handling his tree like this and try to work on it

07:37 <lumag> krzk, when I picked these patches, the offending patch had your r-b tag, so I was not worried about the DT-bindings.

07:38 <lumag> krzk, for every tree there is a delay between patch being submitted and then pushed to the tree. Otherwise other parties will not have time to react

07:38 <krzk> lumag: it is not a problem that patch needing corrections was merged. This is why we have follow ups, bu there follow-up (v3 and v4) are waiting and they should have invalidated next immediately

07:38 <lumag> Please define 'immediately'.

07:39 <krzk> the moment vN+1 is coming and you intend to replace your patches, not do it incrementally, you should drop vN or even replaced it, so no one gets confused

07:42 <krzk> Anyway, if you think it will be perfectly fine if every maintainer works like this, then sure, no problem

07:45 <lumag> krzk, no, it is not perfectly fine. In the perfect world every maintainer reviewes patches within a day or so, picks them as soon as they are ready and never does any other mistakes. We are not living in a perfect world for some unfortunate reason. So we all make mistakes sometimes. Everybody has delays, etc. So, thanks for pointing out the issue. Please excuse me for you having to work on the issue that was already fixed and pending on my side.

07:46 <krzk> lumag: apologies, I thought it is normal process, that's why I discussed.

07:46 <krzk> lumag: I apologize for the tone and complaining.

07:47 <lumag> krzk, n/p.

07:47 <JIaxyga[m]> Marijn: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/5e0a8dada006832d3c0511fdc7903c68474cad87/arch/arm64/boot/dts/qcom/sdmmagpie-sde-display.dtsi#L806 Another small part of the dts panel

07:48 <lumag> krzk, I have a process/script to generate `b4 ty` mails, but sometimes it fails/skips some of the patches.

07:52 <Marijn[m]> JIaxyga: exactly what I need: `qcom,display-topology = <1 1 1>;`

07:53 <Marijn[m]> JIaxyga: do you have an environment where you can boot your downstream kernel? Otherwise we'll add the 1:1:1 topology to mainline and see if it works :)

07:54 <JIaxyga[m]> Marijn[m]: I have android in dualboot if it helps. downstream kernel is not ported to pmos

08:01 <lumag> JIaxyga[m], yes, note that your topology has 1 DSC encoder, while upstream uses 2 currently.

08:02 <Marijn[m]> JIaxyga: cool: I'm not sure if it makes sense to try the `2 2 1` topology on downstream, or if we might miss a workaround somewhere

08:02 <Marijn[m]> lumag: do you think the topology could affect video-mode here, or is dscmerge "supposed to" make that all opaque?

08:03 <lumag> I have not checked whether we support working without DSCmerge ATM.

08:04 <Marijn[m]> No, sure, besides changing num_lm, num_dsc, and some other counters down to 1, DSCmerge might be enabled unconditionally elsewhere

08:07 <Marijn[m]> We will also have to turn off DSC_MODE_SPLIT_PANEL and DSC_MODE_MULTIPLEX (the latter will turn off automatically when dpu_encoder_use_dsc_merge() returns false)

08:08 <Marijn[m]> And enc_ip_w = intf_ip_w / 2 shouldn't be divided by 2

08:33 <Marijn[m]> JIaxyga: try this

08:33 <Marijn[m]> I tested it on SM8350 (DPU 1.2 blocks though...) and no regressions. Perhaps I should try on SM8150 as well

08:34 <Marijn[m]> (That is also why I am not really expecting this to fix anything... The panel should be oblivious to the topology as it all ends up in one stream after DSCMerge, AFAIU)

08:36 <JIaxyga[m]> Marijn[m]: Thanks. I will test when Im home

08:46 <JIaxyga[m]> Marijn: I think adomerle: can test this too on vayu (poco x3 pro) sm8150 with video mode and topology 1 0 1 fixing your patch-hack a bit

08:56 <Marijn[m]> JIaxyga: Are you sure it's not `1 1 1`? It means `lm_count dsc_count intf_count`

08:56 <Marijn[m]> Or does Vayu come without DSC? Then the patch is worthless to test because non-DSC already uses 1 0 1 topology on mainline

08:56 <Marijn[m]> (Or do we use 2 LMs in some cases? I don't remember...)

08:59 <Marijn[m]> Nvm, 2 LM is only used for wide displays (or when using two physical interfaces)

09:01 <JIaxyga[m]> Oh wait, right. There is also 1 1 1

09:01 <Marijn[m]> Yup

09:01 <Marijn[m]> Okay, 1 1 1 seems to work on my SM8150 device

09:01 <Marijn[m]> (USB broke, but that's for another day)

10:02 <Tooniis[m]> <Marijn[m]> "Tooniis: -22 during initialize..." <- it works now but I get these... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/YUfuPucxQtuOeTgoqhWkqbCe>)

10:12 <Marijn[m]> Tooniis: has it worked before? JIaxyga is also bringing up a video-mode panel (albeit with DSC on sm7150). Which SoC are you on?

10:21 <JIaxyga[m]> <Marijn[m]> "Tooniis: has it worked before..." <- I got a very distorted picture, when I tested dsc on v6.1 or v6.2. But it was plausible. If I changed the volume, then distortions changed in the place where the volume level was displayed

10:21 <JIaxyga[m]> I can try to find a video

10:22 <JIaxyga[m]> Maybe something has changed critically since that time

11:32 <Tooniis[m]> <Marijn[m]> "Tooniis: has it worked before..." <- yes on 6.3 at least

11:33 <Tooniis[m]> to be clear, it works despite these messages

11:33 <Tooniis[m]> im on msm8996

11:44 <Marijn[m]> JIaxyga: I'm sorry for not keeping up with all the many broken-panel reports on various configurations here (we almost need a table...), what do you observe now? Colorful distortion is good (especially if you see where it changes), that means the panel is properly initialized and that data is flowing, just that the DSC setup is very likely incorrect/mismatching (which is a given on older kernels).

11:44 <Marijn[m]> Tooniis: oh, right. Is it refreshing slower though? Perhaps worth bisecting that

11:45 <Marijn[m]> Tooniis: are you on the mdp5 or DPU codepath? The latter hasn't yet landed afaik

12:07 <JIaxyga[m]> <Marijn[m]> "JIaxyga: I'm sorry for not..." <- It was on v6.2

12:07 <JIaxyga[m]> <JIaxyga[m]> "1.mp4" <- Now I'm getting this

12:08 <JIaxyga[m]> I havent tried your patch yet. Ill be home in three hours

12:10 <adomerle[m]> Log with applied patch

13:02 <Tooniis[m]> <Marijn[m]> "Tooniis: oh, right. Is it..." <- I got the errors only right after panel init

13:03 <Tooniis[m]> I didn't notice any change in refresh rate, unless it only happened right after init as well

13:03 <Tooniis[m]> <Marijn[m]> "Tooniis: are you on the mdp5..." <- whatever is in master currently

13:03 <Tooniis[m]> ig mdp5

13:25 <aka_[m]> konradybcio: so how we do about max rate of hfpll lpass split?

13:25 <aka_[m]> *and

13:26 <konradybcio> would setting it to 2.something break anything for you?

13:26 <aka_[m]> No

13:27 <konradybcio> then let's use that

13:27 <aka_[m]> Free oc if we do so

13:27 <konradybcio> hm

13:27 <konradybcio> but does it reach 2.x if you don't ask it via opp

13:27 <aka_[m]> Tho my 8976 is burning hot anyway

13:28 <aka_[m]> konradybcio: Why it should

13:28 <konradybcio> just wanna make sure

13:28 <aka_[m]> Isn't it just guarding set_rate?

13:28 <konradybcio> think so

13:28 <konradybcio> but some crazy drivers may have something like "start at max"

13:29 <aka_[m]> I enable cores at almost lowest possible multiplier for pll settings so stock spmi values might not be needed to be guarded too much

13:31 <aka_[m]> konradybcio: Here it says booted at x freq switching

13:32 <aka_[m]> I was unable to see it outside of opps

13:33 <aka_[m]> Worst case scenario preboot pll in lk2nd

13:45 <Marijn[m]> JIaxyga: that's unfortunate. Can you possibly reproduce your 6.2 driver and DTS on -next so that we can start working up from there? Or go back to your 6.2 branch and see if it's still colorful and broken?

13:45 <Marijn[m]> Those flashes and timeouts could mean anything to me...

13:46 <Marijn[m]> adomerle: looks like your panels isn't even probing thanks to some pinctrl clash... Fix that first :)

13:46 <Marijn[m]> panel*

13:47 <Marijn[m]> Or is it and am I just mistaking TS probe for panel probe?

13:47 <Marijn[m]> There's barely any DSI logs

14:05 <adomerle[m]> <Marijn[m]> "Or is it and am I just mistaking..." <- yes, idk why there are so few DSI logs, now I’m building with the ts driver disabled

14:20 <Marijn[m]> adomerle: it could also be me erroneously expecting my own dsi/dpu debug messages... But I thought there was more. Maybe drm.debug might help

14:21 <adomerle[m]> Marijn[m]: that log already with drm.debug=0x3

14:24 <Marijn[m]> Then there should be much more

14:29 <Marijn[m]> Tooniis: I just ran into https://lore.kernel.org/linux-arm-msm/e644a590-27f6-0eed-af58-097677beaf13@rocketmail.com/ where te same timeout" log spam was brought up while the panel works nominally

14:36 <JIaxyga[m]> <Marijn[m]> "0001-drm-msm-dpu-Hack-in-1-1-1-..." <- Sad. Nothing has changed

14:47 <Marijn[m]> JIaxyga: so the timeout messages turn out to be a common issue even if the panel works, then it's just the panel not really interpreting this DSC data and we'll have to look elsewhere with all the previous "video mode DSC is untested/unimplemented" context in mind

14:48 <Marijn[m]> Maybe I or someone else will have to do a pass over dsi_host.c for all the video-mode DSC-specific register writes (dump their values on mainline vs downstream, then compare)

14:48 <Marijn[m]> Given that the PPS is also printed on mainline, it's invaluable to print and back that up on downstream as well to have a reference

14:55 <JIaxyga[m]> <Marijn[m]> "JIaxyga: so the timeout messages..." <- Im only getting timeouts with this commit: https://github.com/sm7150-mainline/linux/commit/44866938977966735bcbbcf8029717e456dd2f7f

14:57 <JIaxyga[m]> The only error I get without this commit is:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/ktLDTpYlwguapBdbGIrzSIvN>)

14:58 <Marijn[m]> No you definitely have to apply prepare_prev_first=true unless reverting those bridge patches

14:58 <Marijn[m]> There are two afaik, konradybcio had them reverted a while ago on our development branch

14:59 <Marijn[m]> You don't loose anything for trying though, revert drm/msm/dsi: More properly handle errors in regards to dsi_mgr_bridge_power_on() and drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset

15:00 <Marijn[m]> And then of course keep that prepare_prev_first=true commit dropped

16:25 <adomerle[m]> fixed

20:25 <Marijn[m]> adomerle: looks like the panel is working nominally now?

20:26 <adomerle[m]> Marijn[m]: panel driver yes, but still blank screen

20:28 <Marijn[m]> Something wrong with the backlight?

20:28 <Marijn[m]> Or brightness?

20:30 <adomerle[m]> Marijn[m]: brightness is ok, just a black screen

20:31 <Marijn[m]> Ok means that the backlight is lit?

20:35 <adomerle[m]> brightness is controlled by wled, I'll try to add support to the panel driver

20:35 <adomerle[m]> backlight*

20:40 <Degdag_Med[m]> lumag: rebased on top of trovald/master branch and the panel works only at 30fps , it works fine with solid 60~61fps on Marijn: branch

20:41 <Marijn[m]> Degdag_Med: most of the fixes are on a -next branch (and my branch...) but haven't been picked to Torvalds' master branch yet

20:44 <Degdag_Med[m]> Marijn[m]: I was planing to update linux-postmarketos-qcom-sm8150 that's why .

20:44 <Degdag_Med[m]> I think I'll wait until all changes get to trovald master branch

20:45 <Marijn[m]> Degdag_Med: what was your panel configuration? Most of the DPU changes that affect timing should be in `master on `torvalds/linux`

20:45 <Marijn[m]> * Degdag_Med: what was your panel configuration? Most of the DPU changes that affect timing should be in `master` on `torvalds/linux\`

20:45 <Marijn[m]> * in `master` on

20:45 <Marijn[m]> You can also try on the -next branch, sm8150 should fully work there

20:55 <Degdag_Med[m]> <Marijn[m]> "Degdag_Med: what was your..." <- This is my current panel driver

20:55 <Degdag_Med[m]> <Marijn[m]> "You can also try on the -next..." <- Thanks I'll try it out

20:55 <Degdag_Med[m]> * In reply to @marijns95:matrix.org... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/bxMiYxtXTTGOWySvIjFjamXj>)

20:56 <Degdag_Med[m]> * In reply to Marijn... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/QfdtYMmAMuPhwLROoSgJHYJr>)

20:56 <Degdag_Med[m]> s/trovald/torvalds/

20:56 <Degdag_Med[m]> * In reply to Marijn... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/rksgYPeZZLKhBcstYWrGbKPD>)

20:58 <Marijn[m]> Oh right, a "simple" video mode panel. No DSC, no dual-DSI

21:15 <Degdag_Med[m]> <Marijn[m]> "Oh right, a "simple" video..." <- CMD mode panel

21:18 <Marijn[m]> MIPI_DSI_MODE_VIDEO_BURST isn't for cmdmode right?

21:20 <Degdag_Med[m]> Well that's the result of lmdpdg

21:20 <Degdag_Med[m]> I think it is

21:21 <Degdag_Med[m]> Yeah it's for cmd mode panel