djakov has quit [Remote host closed the connection]
djakov has joined #linux-msm
davidinux is now known as Guest8150
davidinux has joined #linux-msm
Guest8150 has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-msm
ungeskriptet has quit [Quit: ungeskriptet]
ungeskriptet has joined #linux-msm
ungeskriptet has quit []
Guest7959 is now known as go4godvin
<calebccff>
huh so there seems to be some panel regression on 6.5 (the prepare() op is never called on my sdm845 devices), I bisected it down to ("9e15123eca79 drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset"), which landed in 6.3, and 6.4 doesn't have the bug. Nonetheless reverting that commit does indeed fix the issue. Is this a known bug? (cc lumag)
<aka_[m]>
probably on every soc
<Marijn[m]>
Prepare_prev_first?
<Marijn[m]>
Otoh it should be called, just while the host is still unpowered.
pespin has joined #linux-msm
davidinux has left #linux-msm [WeeChat 3.5]
jessica_24 has joined #linux-msm
pespin has quit [Remote host closed the connection]
<aka_[m]>
one weird question
<aka_[m]>
why Venus-4.2 firmware in linux-firmware is venus-4.0 ?
<aka_[m]>
4.0 is used on MSM8976 and 4.2 is used on MSM8953
<aka_[m]>
oh fun
<aka_[m]>
8996 is 4.4
<aka_[m]>
so how it ended with 4.2 inside?
<aka_[m]>
lumag: any idea?
<konradybcio>
my 8996 fw is 4.2 btw
<konradybcio>
maybe it's just old
<aka_[m]>
konradybcio: checked scorpio fw
<konradybcio>
i think firmware versioning is.. a firmware construct
<konradybcio>
venus has a couple of ip versions, these are what matter
<aka_[m]>
still in venus/core.c we version firmware per venus/x.y
<konradybcio>
i'd expect firmware 4.x branch to support the 8996ish venus
<aka_[m]>
will we be able to run 4.4 on any device?
<aka_[m]>
i mean as long as main gen is 4
<aka_[m]>
maybe i should test lol
<konradybcio>
for all I know you may test any firmware so long as PIL accepts it
<aka_[m]>
it does not load 1.10 for sure
<aka_[m]>
msm8976 firmware somehow ship venus.mbn and venus-v1.mbn prob 8952 runs on 1.10
<aka_[m]>
uh freq_table looks a bit dumb
<aka_[m]>
downstream have different freqs/bandwidth combos for enc/dec
<aka_[m]>
do we assume highest one to go with it?
<konradybcio>
half of the code in there is probably dead idk
<Rayyan>
konradybcio: did you see my message on pmos mainline?
<konradybcio>
yes
<konradybcio>
@bamse commit 703db1f5da1e3a62b84356a29c150efa24a2377d breaks display when using shared ops for mdp_clk_src, at least 8226 and 7180 cc Rayyan travmurav
<aka_[m]>
<konradybcio> "half of the code in there is..." <- prob i feel like having real OPP table and way to calculate required bandwidth would look much better