<narmstrong>
Marijn[m]: yes but the config seems to be the same as your sdm845 so yes it’s a new config missing, the screen stays black like a link is missing in the pipeline and the data is not sent to the panel, because without the dsc setup I have a fuzzy display trying to uncompress raw pixels
<narmstrong>
Marijn[m]: I already identified a missing INTF_CONFIG2 bit 15 to enable compressed input, but it’s not enough. But honestly when I look to the registers written the only bits that refers to the DSC merge are the DSC MULTIPLEX bit, but we only set 0 as INTF PP source, is this enough on new HW ?
pevik_ has joined #linux-msm
<Marijn[m]>
abhinav__: ack, cool, I couldn'
<Marijn[m]>
..t find the right bind calls downstream but must not have been looking hard enough :)
<Marijn[m]>
abhinav__: Would love to see a gitlab issue for this, I can write one up later this day with all the necessary context on my end, or reply to one with it if you beat me to it :)
<Marijn[m]>
narmstrong: Yeah for me the screen also stays black now but I'm never fully confident in our panel init sequence and whether the reset line (for example) got flipped again somewhere... Used to get corruption in the past (one of the panels only updated a DSC-compressed block at the top of the screen, in bright random colors. A line down the middle was clearly visible because of slice_width=hdisplay/2), but not sure if that is because we're
<Marijn[m]>
sending uncompressed data to a panel that expects compressed, or the other way around
<Marijn[m]>
narmstrong: For INTF_CONFIG2 I see my 5.4 downstream kernel set BIT(12) for DSC, but only for SDE 6.0.0/7.0.0. Maybe I'm missing that on kona/sm8250 but it shouldn't affect sm8150.
<Marijn[m]>
narmstrong: Yes, I also dove down the path of checking whether both PPs should be bound to the intf, but downstream I can only find PP0 being bound to the INTF. PP0 is still bound do DSC0 and PP1 to DSC1
<Marijn[m]>
I think it's correct, but again I might not have looked hard enough and should do another (register) dump downstream.
krzk has quit [Remote host closed the connection]
pespin has joined #linux-msm
krzk has joined #linux-msm
<narmstrong>
Marijn[m]: yup I didn't find any particular differences either, on my downstream dump bit 12 of INTF_CONFIG2 is enabled, so yeah you should have it for sm8250 and later
<Marijn[m]>
I don't think I have it for 8250 yet, that'd be interesting...
<Marijn[m]>
(I grabbed the phone to test this, but now seems I cannot get to it until the work day is over)
Daanct12 has quit [Remote host closed the connection]
<narmstrong>
there's one diff: MERGE3D_0 is not set downstream in CTL MERGE_3D_ACTIVE
<narmstrong>
honestly I don't see the role of merge3d in dsc merge
<Marijn[m]>
I don't think it should be used at all in this topology
<Marijn[m]>
Downstream does define a 3D_MERGE_DSC topology though :D
<Marijn[m]>
Regardless, I remember trying the disable codepath for merge3d which is what downstream always calls, to no avail
<narmstrong>
anyway, I have a "DSC flush not complete" for 0 & 1 status in CTL
<Marijn[m]>
How do you know that 👀
<narmstrong>
ah ah
<Marijn[m]>
I didn't know there was any debug info available in the status field :)
<Marijn[m]>
One of my patches makes sure the flush actually happens, and I even tried to place the flushes earlier to match downstream
<narmstrong>
oh yeah one diff is CTL_INTF_MASTER is set to INTF1
<Marijn[m]>
That might be correct since DSI is on INTF1
<Marijn[m]>
Unless the indexing is wrong and an intf_idx - INTF_0 was forgotten
<Marijn[m]>
Oh nvm it wasn't ever written, I have a commit from bamse that does that but I don't think it ever got applied :)
<Marijn[m]>
narmstrong: downstream only seems to set it if there is more than one intf (active? for split-display?)
<narmstrong>
Marijn[m]: yeah weird I know, but the bit it set, but adding it doesn't change anything
<Marijn[m]>
Regardless, back to your original comment, what register did you read the status from and what are possible values? Or are outside contributors "not supposed to know" and just keep tasting in the dark?
<narmstrong>
Marijn[m]: I don't know if I can disclose the register offset :-/
<Marijn[m]>
Haha classic qcom, I'm debugging and upsreaming their hardware for free meanwhile 😜
<narmstrong>
Marijn[m]: I have wrong displayed but I have something
<narmstrong>
Marijn[m]: DSI_VIDEO_COMPRESSION_MODE_CTRL_WC(dsc->slice_chunk_size) is missing in REG_DSI_VIDEO_COMPRESSION_MODE_CTRL
<narmstrong>
now I have plenty of dsi_err_worker: status=4
<Marijn[m]>
narmstrong: Right, video mode. The high word shouldn't be used on cmdmode, that's for the second stream?
<narmstrong>
Marijn[m]: exact it's for video mode, for high mode it's programmed
<narmstrong>
*cmd mode
<Marijn[m]>
For CMD the word count sits in REG_DSI_CMD_MDP_STREAM0_CTRL, I fixed that in my most recent patchseries (and the values of all these registers match downstream dumps)
<Marijn[m]>
For us it isn't slice_chunk_size but `wc = msm_host->dsc->slice_chunk_size * msm_host->dsc->slice_count + 1` (as per my series), should it also be that on video?
<narmstrong>
interesting, let me try
<narmstrong>
hmm nop the +1 doesn't help
dliviu has quit [Ping timeout: 480 seconds]
<Marijn[m]>
Did you have a multiplication by slice count, or is that not what downstream does for video mode?
<narmstrong>
slice count is 1
<narmstrong>
but I have the top half of the display duplicated at the bottom half
<Marijn[m]>
But you have working video output at least?
<narmstrong>
I have something displayed, but it's badly uncompressed
dliviu has joined #linux-msm
<narmstrong>
ok now I have a full but wrong display, hdisplay/3 is only for CMD mode, at leas for dsi timings, but they still do a /3 on mode->h_active
<narmstrong>
victory is close!
<narmstrong>
I think I found something: "From Lahaina onwards, for compressed DSI output, widebus should be enabled"
<narmstrong>
abhinav__: is it right we should enable widebus from Lahaina and onwards ? could this explain why I have a fuzzy display ?
<bamse>
narmstrong: how wrong is the picture?
<narmstrong>
bamse: hard to say, it's badly uncompressed, and only the first few lines changes when I change the display content (full back or modetest mire)
<bamse>
narmstrong: widebus gives you more pixels per clock, allowing you to run at lower frequency (or push more pixels than possible at max frequency)...
<Marijn[m]>
bamse: how solid is dispcc nowadays? I'm still carrying `clk: qcom: sm8250-dispcc: Flag shared RCGs as assumed enable` and friends but it doesn't seem to make a difference
<bamse>
Marijn[m]: that was rejected...use clk_ignore_unused always for now
<Marijn[m]>
Also had to add CLK_OPS_PARENT_ENABLE to (byte|pclk)[01]_clk_src to get rid of disp_cc_mdss_pclk0_clk_src: rcg didn't update its configuration.
<bamse>
Marijn[m]: Abel has a patch that moves late_initcall to sync_state, which will help us solve this problem
<Marijn[m]>
bamse: ack thanks, dropping it doesn't make a difference so I'll clear it out of my branches and stick with clk_ignore_nused for now
<bamse>
Marijn[m]: it's been too long since i stared at the details of those particular clocks...could it be that we want that fix? (parent enable...) what do we have on other platforms?
<narmstrong>
Marijn[m]: I had `rcg didn't update its configuration` but only if I add the splash_region...
<narmstrong>
seems when splash_region is present, those clocks gets disabled
<bamse>
the one thing to watch out for is scenarios where we end up reconfiguring an rcg without it's currently configured parent being clocked
<Marijn[m]>
bamse: yeah a few platforms do, qcm2290 / sm6115 / sm6350 / sm6375. Don't know if all those are upstream yet
<Marijn[m]>
I was assuming that might be happening?
<Marijn[m]>
Guess I'll stick to my sm8150 device for now where the panel stays on, I can poke at brightness (and see it and its beautiful corrupted colors change), and when running modetest the top slice flickers in bright colors
<Marijn[m]>
Also, killing modetest causes a blank, and it looks like my DSI_CMD_MDP_STREAM0_CTRL_WORD_COUNT fix (patch sent last week) at least makes it clear the whole instead of half the screen now (in grey instead of black)
<bamse>
Marijn[m]: you got dpu working on 8150? i don't think we have that upstream, right?
<Marijn[m]>
bamse: yes, and I have a Sony Xperia 5 that doesn't utilize DSC where the whole thing was tested on
* Marijn[m]
pokes konradybcio with a stick _again_ to send it or allow me to send i
<bamse>
Marijn[m]: i don't have a mdss node in upstream sm8150.dtsi...
<bamse>
i see, looking forward to see them patches :)
<Marijn[m]>
For anyone interested, this is what Xperia 1 looks like. Framebuffer console, then modetest -v (where only the top slice refreshes with blue colors), and finally ctrl+c where the whole screen blanks
<bamse>
the blue flashing on the top is interesting...
<Marijn[m]>
Yeah, at this point I am unsure if it's DPU sending the wrong data or the panel unpacking the data wrongly
<Marijn[m]>
Time to rip it open and attach a logic analyzer to DSI?
<Marijn[m]>
Or wait for narmstrong to see if there are any useful drive-by fixes that affect cmdmode too
<bamse>
the data rates aren't tinker-friendly
<Marijn[m]>
4k screen, running at 2.5k... Not really :)
cxl000 has quit [Ping timeout: 480 seconds]
cxl000 has joined #linux-msm
pevik_ has quit [Ping timeout: 480 seconds]
<abhinav__>
narmstrong post lahaina, i would certainly enable DSC with widebus enabled because all our verification is only done with that configuration
<narmstrong>
abhinav__: ok
<abhinav__>
narmstrong AFAIK, we didnt enable widebus for DSI yet if i am not wrong
<abhinav__>
we enabled it only for DP
<abhinav__>
so probably the scope of your DSC work is expanding :)
<narmstrong>
abhinav__: yes It’s correct
<narmstrong>
abhinav__: hopefully it won’t be too hard to enable!
<narmstrong>
Indeed for dp it’s already present
<Marijn[m]>
narmstrong: for sending anything, are you blocked on me resending DSC patches v2?
<narmstrong>
Marijn[m]: nop not yet!
<Marijn[m]>
narmstrong: Ack, great! Trying to prioritize things now, and after finishing a drm/msm GitLab issue I'll continue on getting INTF_TE out :)
<narmstrong>
Marijn[m]: once I have a functional display it’ll be a different story :-p but I don’t expect anything before next year
<narmstrong>
Marijn[m]: having CMD mode working would be much better than video mode so I’ll be interested in that also!
<Marijn[m]>
Hehe, no hobby-Christmas-holiday for me (either), I'll only end up doing things at random times during the day/evening