ChanServ changed the topic of #linux-msm to:
minecrell8 has joined #linux-msm
minecrell has quit [Ping timeout: 480 seconds]
malvi[m]1 has joined #linux-msm
<steev> The joys of android that I do not miss
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
anholt_ has quit [Remote host closed the connection]
anholt has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
<aka_[m]> my DS compiling ended on msm-3.10 and i quite enjoy that fact
<alfayt[m]> <alfayt[m]> "photo_2022-12-03_20-34-03.jpg" <- Yeah it's just that I'm not able to make mainline work on my phone bc of usb
pevik_ has joined #linux-msm
<aka_[m]> looks like it depends on something
<aka_[m]> not enabled
<aka_[m]> phys depends on regulators,clocks
<aka_[m]> you could try make it output /sys/kernel/debug/clk/clk_summary
wgetux[m] has joined #linux-msm
pevik has quit [Remote host closed the connection]
pespin has joined #linux-msm
pevik has joined #linux-msm
flto has quit [Remote host closed the connection]
flto has joined #linux-msm
Degdag_Med[m] has joined #linux-msm
dliviu has quit [Ping timeout: 480 seconds]
pevik_ has quit [Ping timeout: 480 seconds]
dliviu has joined #linux-msm
<JIaxyga[m]> Hey Marijn. ungeskriptet told me that you discussed dsc a couple of days ago. Then you were talking about dsc in conjunction with the cmd mode panel. I tried to get dsc to work on sm7150 with video mode panel. Unfortunately, my attempts were unsuccessful but probably I do not have enough knowledge in this direction. What could you advise?
<konradybcio> i don't know too much either, but "i tried, doesn't work" is a bit too vague to help you out
<konradybcio> describe what you tried and what you observed so that the people you pinged may try to help you
<Marijn[m]> JIaxyga: Can you describe what has been "unsuccessful"? I'm rather unfamiliar with sm7150 nor with your specific device setup, can you tell me which branch of contains your DPU driver (since it's not upstream yet, go get that done!) and panel driver?
<Marijn[m]> I quickly scrolled through and see that an older patch was still using `bits_per_pixel = 8`, you better fixed that up as per the suggestions I sent straight to aka_ right above
<Marijn[m]> I did discover another bug in the DSC code today (...), on SoCs that actively configure the CTLs (DPU_CTL_ACTIVE_CFG), does sm7150 have that?
<Marijn[m]> (Any CTL on V1.0.0 has)
<Marijn[m]> (But mainline doesn't describe CTL versioning, only features, so it's a bit inconvenient to map downstream to mainline...)
<JIaxyga[m]> Well. I am getting some image output which is accompanied by artifacts (Even though dsc is missing from the panel driver and dpu). If I add dsc to the panel and dpu I get this when I wake the panel from sleep
<JIaxyga[m]> This video is recorded on sm8150 but i get the same
<JIaxyga[m]> Artifacts also change if something happens on the screen
<JIaxyga[m]> panel dts
<JIaxyga[m]> <Marijn[m]> "I did discover another bug in..." <- grep does not find DPU_CTL_ACTIVE_CFG in downstream
<Marijn[m]> 🤦‍♂️DPU doesn't exist downstream
<JIaxyga[m]> JIaxyga[m]: any DPU_CTL*
<Marijn[m]> <JIaxyga[m]> "dsc.jpg" <- Did you compare this with downstream? It looks quite... empty...
<JIaxyga[m]> Oh sorry, I'm dumb XD
<Marijn[m]> The corruption looks exactly like what I see on my DSC devices, so it's quite likely
<Marijn[m]> Again, just share me the kernel tree that you are currently using so that I can make sure you have my patches and have the panel driver and DPU HW set up correctly
<Marijn[m]> <JIaxyga[m]> "This video is recorded on sm8150..." <- So this is an sm8150 device? Makes things easier because I know it has `DPU_CTL_ACTIVE_CFG` and would hence _at least_ need a similar fix
<Marijn[m]> JIaxyga[m]: Looks like it's using `sm8150_ctl` so you have active cfg on 7150
<JIaxyga[m]> Marijn[m]: No, I'm just too lazy to upload my video. I've pasted this as an example because I'm getting the exact same thing. But sm7150 is quite similar to sm8150. I have poco x3 nfc (surya sm7150), and on the video poco x3 pro (vayu sm8150)
<Marijn[m]> Ack clear
<JIaxyga[m]> Probably the correct values are 0x81000 and 0x81400. (These I use in the local repository)
<Marijn[m]> Yes those are the right offsets
<Marijn[m]> Where can I find your panel driver on Two of the panel drivers on the first two pages don't include a DSC config
<Marijn[m]> <JIaxyga[m]> ""; <- I guess this but it doesn't contain a DSC configuration at all :)
<JIaxyga[m]> Marijn[m]: The previous code caused a compilation error and I temporarily dropped it. Therefore, I have not yet tested dsc on 6.1. Now I'll take care of it
<Marijn[m]> <Marijn[m]> "aka_: You can recommend them..." <- So, from some preliminary digging on your branch, it looks like you have quite a bit to do... Let's see if I can whip up a little todo list for your convenience based on ^ message I sent to aka_ yesterday
<Marijn[m]> JIaxyga ungeskriptet since we'd have so much ground to cover, I just opened a PR with everything that you need, including some of my patches on the lists that will only hit 6.2:
<Marijn[m]> I'm only skeptical about DTS specifying one DSC encoder whereas afaik mainline currently enforces two (for perf/efficiency, don't know if it has an effect/affect on the end result), but that's an area I'll have to investigate for my own devices as well (apologies to Dmitry who explained this to me one day, but I forgot and would have to look it up somewhere in my notes...)
<JIaxyga[m]> You so are fast. Thanks, I will test this now
<Marijn[m]> Yeah so I think mainline currently only added SDE_RM_TOPOLOGY_DUALPIPE_DSC (two DSC), while I think you may need SDE_RM_TOPOLOGY_SINGLEPIPE_DSC for this to work, but it's driven by userspace (topology_name DRM property) downstream
<Marijn[m]> But we will see, let's get you started with this (which I haven't compile tested, sorry)
<JIaxyga[m]> /usr/bin/aarch64-alpine-linux-musl-ld: drivers/gpu/drm/panel/panel-huaxing-nt36672c.o: in function `nt36672c_prepare':
<JIaxyga[m]> /mnt/linux/.output/../drivers/gpu/drm/panel/panel-huaxing-nt36672c.c:224: undefined reference to `drm_dsc_pps_payload_pack'
<JIaxyga[m]> > <> ```... (full message at <>)
<Marijn[m]> The patch in my PR has `#include <drm/display/drm_dsc_helper.h>`, right?
<JIaxyga[m]> Marijn[m]: Yes, that's right
<Marijn[m]> Fwiw just take the PR as-is so that I don't end up wondering if you have everything :)
<Marijn[m]> That is why I made this into a PR instead of a 10-step tutorial of which patches to pick and what changes to make
<Marijn[m]> 🎉
<JIaxyga[m]> Marijn[m]: But the compilation error is not resolved
<Marijn[m]> I misread it as a compiler error first (not finding the symbol) but it's a linker error
<JIaxyga[m]> wait
<JIaxyga[m]> just still "m"
<JIaxyga[m]> Compilation successful 🎉
<Marijn[m]> Yay! Now only to be disappointed by corruption on the screen
<JIaxyga[m]> <Marijn[m]> "Yay! Now only to be disappointed..." <- Well, corruption has changed
<JIaxyga[m]> Not for the better
pespin has quit [Remote host closed the connection]
<aka_[m]> lumag: what are we going to do about this infamous ubwc on sm6115
<aka_[m]> register claims its v2 yet as you seen downstream uses ubwc v1 inside sde_hw_sspp but elsewhere(sde_hw_top) query register
<aka_[m]> and use ubwc-static value
<aka_[m]> im not sure if register written in sspp.c and hw_top is same tho
<aka_[m]> best would be if i can build android kernel with dev_mem support and query what it leave inside it
<bamse> arnd: thank you
<aka_[m]> hmm
<aka_[m]> it appears ubwc value is appearing in multiple places
<aka_[m]> per sspp vp/vig
<Marijn[m]> JIaxyga: At least DSC params look "correct" now, filled in the same pattern as what I have here (with the hardcoded rc paramets etc) and only differing where your screen and packet sizes differ.
<Marijn[m]> (By eyeballing it, I can't diff a screenshot of plaintext 😝)
<Marijn[m]> But I think I cannot help you much more right now as I am still looking into the same issue here on the newer (>845) SoCs. At least good to know that video-mode is also broken and it isn't just me and some half-unfinished cmdmode changes elsewhere
<Marijn[m]> JIaxyga: let me know if you can extract the topology value used downstream
<JIaxyga[m]> Marijn[m]: Okay, thanks for that too. I wish you success
<JIaxyga[m]> Degdag_Med: I think it will be interesting for you too
<aka_[m]> ok now i fuckin wonder what is main difference between UBWC_DEC_HW_VERSION and ubwc_version in hwcatalog
<aka_[m]> ok, its really not that easy to understand what kind of hacks they are doing there
<Marijn[m]> JIaxyga: I'll let you know when I have made more progress :)