ChanServ changed the topic of #linux-msm to:
Marijn[m] has quit [Server closed connection]
Marijn[m] has joined #linux-msm
IvanBelokobylskiy[m] has quit [Server closed connection]
IvanBelokobylskiy[m] has joined #linux-msm
DavidHeidelberg[m] has quit [Server closed connection]
DavidHeidelberg[m] has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
travmurav[m] has quit [Server closed connection]
travmurav[m] has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
peremen[m] has quit [Server closed connection]
peremen[m] has joined #linux-msm
Intdtti has joined #linux-msm
Intdtti1 has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Server closed connection]
Tooniis[m] has joined #linux-msm
Guest565 is now known as go4godvin
dliviu has quit [Server closed connection]
dliviu has joined #linux-msm
<lumag> aka_[m], regarding the swizzle. Patches are welcome. It well might be that we missed it, while adding support for newer revisions
<aka_[m]> lumag: i think its quite messy.
<aka_[m]> swizzle appears to be used when UBWC is active which is something about bandwidth compression right
<aka_[m]> SM6115 writes static UBWC value in HW_TOP on downstream which i did in mainline hw_top at the end
<aka_[m]> so work on swizzle/ubwc might be needed when we get high resolution panels where compression will be used.
<aka_[m]> Not a case on low end chips like sm6115 where DPU appears to be capped at 1080p
<aka_[m]> and me trying to bring some downstream code which i don't understand is quite dumb idea to waste someone's time xD
<lumag> aka_[m], nah, ubwc is about compressing textures, not about display compression/resolution
<aka_[m]> DSC is about display?
<lumag> yes
<lumag> Note that UBWC_STATIC& Co are set at the msm_mdss.c
<aka_[m]> yes
<aka_[m]> thats where i set default
<aka_[m]> downstream does it in ubwc_hw_reset in sde_mdss_top or something
<aka_[m]> but only if UBWC is 2.0
<aka_[m]> and does some stuff to it if fetch type is different than X
<lumag> yep
<lumag> But the config is mostly static
<aka_[m]> does it reset to some default value once MDSS block is turned off?
<aka_[m]> it was giving me 0xe after i got screen shutdown after writing with mem_write32
<aka_[m]> lumag: any comment on that patch from Loic
<lumag> which one?
<aka_[m]> it appears to hit sm6115,not sure how Marijn haven't reported that on his sm6125
<aka_[m]> it has same PHY
<aka_[m]> and they had dpu working
<lumag> aka_[m], basically, that's the question, which we never fully understood. We have DSI working on earlier PHYs without any issues. So, what is causing the issue here.
<aka_[m]> uh earlier
<aka_[m]> earlier ones has no byte_intf clock
<aka_[m]> like 8996/8994/8953/660
<aka_[m]> its just byte there
<lumag> 660 has byte_intf
<lumag> And it is 14nm
<aka_[m]> oh it has it
<aka_[m]> maybe it depends on panel
<lumag> yep
<lumag> So, before accepting this change, I'd like to understand the causes and the issues.
<aka_[m]> hmm
<aka_[m]> wait a second
<aka_[m]> i might have good person to test on sdm660 🤠
<aka_[m]> i hope i can get this lazy slacker to be useful once
<aka_[m]> <lumag> "So, before accepting this change..." <- in short on sm6115 Redmi 9T smartphone display was just black and nothing on screen
<aka_[m]> how are these clocks connected to panel itself no idea cuz im some dumb fuck 🤠
<konradybcio> >uh it appears mmio read when clocks and bus is disabled ends in reboot
<konradybcio> yes, if you try to access a gated piece of hw you either get 9600005/96000010 or you get a bite and reboot
minecrell has quit [Server closed connection]
<konradybcio> > <@aka_:matrix.org> Marijn: lumag_ robclark... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/uwZTlpOtoRSyIQCXOybAlAnB)
minecrell has joined #linux-msm
Intdtti has quit [Remote host closed the connection]
<konradybcio> <aka_[m]> "it appears to hit sm6115,not..." <- maybe all other socs had some edge cases where FREQ/2 and FREQ correspond to the same power state or something.. or maybe just sheer luck..
Intdtti has joined #linux-msm
<aka_[m]> or cmd panels having some lower requirement?
<konradybcio> idk, there are devices with both cmd and vid panels working
<konradybcio> even going back to msm8974 and 28nm
<aka_[m]> uh quick reminder if you havent followed to top,
<aka_[m]> Byte_intf is quite new clock there
<aka_[m]> appears to start somewhere around sdm660
<konradybcio> drivers/clk/qcom/dispcc-sm6350.c... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/XiQOiUQIjRYnNmJLZEIDPgVH)
<konradybcio> 660 is the oldest i guess
<aka_[m]> quite new it looks
<konradybcio> but we had video mode panels on 10/10+ and cmd panels on xa2 series working
<konradybcio> perhaps it was just luck, no idea
<aka_[m]> wait
<aka_[m]> its only on 14nm phy
<aka_[m]> for lower its fine
<aka_[m]> it has to be half rate
<konradybcio> 660 uses 14nm iirc
<aka_[m]> 660/2290 only are ones using byte_intf
<aka_[m]> from 14nm phy
<aka_[m]> still something must be on the topic if it fixes it on qcm2290/sm6115
<aka_[m]> quite annyoing we cannot read easily freqs on downstream
<konradybcio> /sys/kernel/debug/clk/dispcc*/clk_rate?
<aka_[m]> as you might know sometimes rates are just 0
jojo_autoboy[m] has quit [Server closed connection]
jojo_autoboy[m] has joined #linux-msm
Intdtti1 has joined #linux-msm
Intdtti has quit [Ping timeout: 480 seconds]