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 https://github.com/sm7150-mainline/linux 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 https://github.com/sm7150-mainline/linux/commits/v6.1-rc8? Two of the panel drivers on the first two pages don't include a DSC config
<Marijn[m]> <JIaxyga[m]> "https://github.com/MiCode/Xiaomi..."; <- https://github.com/sm7150-mainline/linux/blob/v6.1-rc8/drivers/gpu/drm/panel/panel-huaxing-nt36672c.c 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: https://github.com/sm7150-mainline/linux/pull/15
<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]> > <@jiaxyga:matrix.org> ```... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/uFwOwiHfTifUrcABchQZKzWd>)
<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]> CONFIG_DRM_DISPLAY_HELPER=y
<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 :)