Daanct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
BobBeck has joined #linux-msm
anholt_ has joined #linux-msm
anholt has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
<Nia[m]>
hi all! working on getting display up w/ DSC for oneplus-lemonadep (sm8350); I have a driver that goes as far as initializing it post-reset (kinda messy rn w/ a lot of commented out code, but it's this [1] with devicetree here [2]) and the DPU is erroring out with:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/QGLmSIhAZzrtWbQdpGcsAnTI>)
<Marijn[m]>
Yikes why is the mode (and other unused vars) in a separate header 😬
<Nia[m]>
I had a major rewrite 😓 back when I had ambitions of making it work on multiple devices, ha
<Nia[m]>
obviously too small to justify that now, I'm just trying to get it working and then I'll refactor
<Marijn[m]>
You can definitely do that with just a C file and some compatibles, as many other drivers do
<Marijn[m]>
That said though there's definitely the need for a shared header file across all these Samsung Driver ICs... Their commands are mostly identical
<Nia[m]>
Marijn[m]: that's what I'm gonna do. I was going to reimplement some more functionality from the downstream Google Pixel driver which did have a huge header but then realized this is a pain on its own and never bothered to merge the header back in
<calebccff>
Marijn[m] has anyone made some docs on all the common samsung commands? Would be great to start to understand what is actually going on with these panels
<Marijn[m]>
calebccff: so far I only really understand the mcp/mtp key (even has a different name across drivers)
<Marijn[m]>
On Sony we have quite a few similar panels and 95% of the commands appear to not even make a difference
<Marijn[m]>
But as said, that's the only sure thing that really is common. The rest is magic commands that no-one really knows the meaning of
<Marijn[m]>
Oh and the WRCTRLD
<Nia[m]>
interesting, alright
<konradybcio>
MCS is Manufacturer Command Set according to some comment in some file
<aka_[m]>
<Marijn[m]> "But as said, that's the only..." <- I guess ones who get hold of datasheet from this csdn site might know
<Marijn[m]>
konradybcio: sure, so you get access to a bunch of "manufacturer only" commands?
<Marijn[m]>
DCS is such a nice standardization spec :P
<konradybcio>
guess so
<konradybcio>
wonder if the lock acts as "commit" and can we maybe skip locking for sequential accesses
<aka_[m]>
So great that latest open spec sheet is like 1.3 and we are at like 2.x
<Nia[m]>
<konradybcio> "wonder if the lock acts as "..." <- downstream google drivers do this, after unlocking they only relock at the end of the init sequence
<Nia[m]>
(or w/e sequence is being performed)
jhovold has quit [Ping timeout: 480 seconds]
<Marijn[m]>
Yeah I've skipped the lock(); unlock(); pairs in my drivers as well, no effect so it's probably fine to commit (or simply exit that mode) only once
<Nia[m]>
any clue regarding my original issue, though? still haven't figured out a proper lead
<Marijn[m]>
Never seen it, but you're pushing quite a high resolution and refresh rate. Are you sure this isn't a dual-DSI panel?
<Marijn[m]>
It's hard to find the right downstream dts reference for "lemonadep" amidst all these hack repos, but one of them points to amb670yf01 which is exactly what I'm bringing up for Sony devices... Dual DSI and DSC :(
<Nia[m]>
doesn't seem to be? only 2 DSIs are exposed and the 2nd one seems to be for dp alt mode
<Marijn[m]>
Topology definitely points to single-DSI
<Nia[m]>
current angle of attack is "manually reverse-map the pps bitfield from downstream and pray it works"
<Marijn[m]>
It's definitely a cmdmode panel so your porches might simply be too high, they are ignored downstream in favour of computing a per-packet transfer overhead instead
<HappY[m]>
Nia[m]: Okay so you also has dsc panel which panel generator you used?
<Nia[m]>
Marijn[m]: can I just... guess as to the porch values, or?
<Nia[m]>
HappY[m]: none, I'm doing the DSC part of this manually
<abhinav__>
Nia[m] I have seen this issue last week while bringing up another high resolution panel at 120Hz, I will investigate a proper fix for this and post it by next week
<HappY[m]>
Nia[m]: Okay.. 👌
<Nia[m]>
oh? that's lovely to hear :D
<Marijn[m]>
There's a panel generator available fwiw
<Marijn[m]>
abhinav__: are you looking into dual-DSI DSC support yet?
<Marijn[m]>
i.e. 2:2:2 topology?
<Nia[m]>
Marijn[m]: yeah, but it doesn't do DSC stuff properly. I used it for the base driver
<Nia[m]>
ik there's a patchset that adds some support but it seems to need a bit more manual work afterwards too
<Marijn[m]>
Panel drivers have always needed manual support, but it's a start
<Marijn[m]>
Manual post-processing*
<Nia[m]>
Fair enough
<abhinav__>
Regarding your ongoing bringup, you can force two SSPPs by changing VIG_SC7180_MASK in sm8350_sspp to VIG_SC7180_MASK_SDMA and changing max_linewidth in sm8350_dpu_caps to 1080 so that it forces the condition to use smartDMA
<abhinav__>
Marijn[m] no, this was a high res eDP bringup
<abhinav__>
and i hit the same issue, so worked around it for now
<abhinav__>
by using two SSPPs
<abhinav__>
need to investigate a bit more to come up with the right fix
<Marijn[m]>
abhinav__: okay good to know, I'm working on that :)
<Marijn[m]>
If you have anyone running into it or looking into it, would love to have a chat because it's not fully working yet and I only have a sample-size of 1 to test with
<HappY[m]>
<Marijn[m]> "There's a panel generator..." <- I am using your one.. but display is black.. even no error reporting
<abhinav__>
Regarding your dual DSI DSC issue, we are not working on it but can assist you , pls post your query
<HappY[m]>
I can't see any issue in my dmesg.. but display is black
<Marijn[m]>
abhinav__: perhaps it would help if I create another msm/drm issue
<abhinav__>
Marijn[m] sure, may i know who maintains the panel generator now?
<Marijn[m]>
abhinav__: in short: after taking and improving lumag's Active-CTL patches, and converting - as far as I'm aware - most of the DPU-DSC and dsi_host code to support this topology, I now get the left side (one of the interfaces) of the screen to fill up with colorful DSC corruption, though about every 5th DSC block isn't corrupted and contains framebuffer console output that I expect
<Marijn[m]>
At this point I'm unsure if the issue is on the DPU level, the DSI level, or the panel level, but there are quite a few out-of-tree changes needed to even get this far
<Marijn[m]>
abhinav__: I think minecrell and other MSM8916 developers have merge rights there?
<lumag>
Marijn[m], this is close to what I observe on Pixel3 / sdm845 if panel is reset. Some of the stripes are correct, most are not.
<Marijn[m]>
lumag: oh good to know; I think I've tried not resetting the panel, maybe it means the DSC config (or any other DCS command) is incorrect
<Marijn[m]>
The silly thing is that this is on one of the SoCs that "run Linux in a VM", here downstream skips about half of the commands (including sending DSC PPS) and other configuration...
<lumag>
Marijn[m], I think it should reconfigure the panel after full suspend-resume cycle?
<Marijn[m]>
Did a dumpster-dive through old messages: this is what it looks like currently
<Marijn[m]>
lumag: it never sent the PPS, I inserted quite some debug to validate
<lumag>
Ugh :-(
<Marijn[m]>
However, I also disabled that if (vm) return; downstream, observed/confirmed that it got sent, and it didn't affect the panel
<Marijn[m]>
That way I could also diff the PPS with mainline, and it's identical at least....
<abhinav__>
Marijn[m] yeah, I would take a hexdump of the PPS and compare it, it looks a lot like decode issue arising from incorrect pps ... or a mismatch between pps and encoder
<Marijn[m]>
abhinav__: gone through all that already, also did it for many of the registers related to the DSC, CTL, DSI and INTF blocks
<Marijn[m]>
HappY🤗: Yep, it's missing a simple `ret = mipi_dsi_dcs_set_display_on(dsi);` at the end of `samsung_ams662zs01_on()` ;)
<Marijn[m]>
And later you'll want to use the kernel to generate a PPS for you, but one thing at a time
<Marijn[m]>
HappY🤗: actually because you generated it with the panel generator it's there... After it works don't forget to remove the long DSC write command (`mipi_dsi_dcs_write_seq(dsi, 0x9e, ...`) in favour of `mipi_dsi_picture_parameter_set()`
<HappY[m]>
Marijn[m]: If you don't mind.. can you edit it ? I actually unable to understand