srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #linux-msm
pevik_ has joined #linux-msm
pevik_ has quit []
pevik_ has joined #linux-msm
pespin has joined #linux-msm
pespin has quit []
pespin has joined #linux-msm
svarbanov has joined #linux-msm
svarbanov_ has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-msm
pevik__ has joined #linux-msm
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
Danct12 has quit [Remote host closed the connection]
pevik_ has quit [Quit: Reconnecting]
pevik_ has joined #linux-msm
pevik_ has quit [Quit: Reconnecting]
pevik_ has joined #linux-msm
pevik_ has quit []
pevik_ has joined #linux-msm
pevik_ has quit [Quit: Lost terminal]
pevik_ has joined #linux-msm
pevik_ has quit [Quit: Lost terminal]
pevik_ has joined #linux-msm
<z3ntu>
Oh man, CHECK_DTBS=1 seems to be broken again on 6.2-rc8 at least..
<z3ntu>
make[2]: *** No rule to make target 'arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dtb'. Stop. with make CHECK_DTBS=1 qcom/sm7225-fairphone-fp4.dtb, without it works fine
<konradybcio>
works on next-20230210
<konradybcio>
also i'll share something fun i found yesterday
<konradybcio>
make ARCH=arm64 CHECK_DTBS=1 ../../../arm/boot/dts/qcom-msm8974-sony-xperia-rhine-honami.dtb works, you can check a32 dtbs!
<z3ntu>
yeah cherry-picking ec201955a53be4b57a467f7160724ff06289cead seems to work..
pevik_ has quit [Remote host closed the connection]
<aka_[m]>
lumag: with patches there is still something wrong with a510
<aka_[m]>
I'm now heading job so cannot provide much logs
<lumag>
if you can provide addtinal details, that would be great
<aka_[m]>
Maybe I have some ultra legacy old firmware
<lumag>
aka_[m], well might be.
<lumag>
Also can you please check if that's the same issue or not. Go to the msm_ioctl_submitqueue_new() and replace args->prio with 1.
<aka_[m]>
lumag: what exactly will I need to provide, full log got sure
<aka_[m]>
Is adreno firmware per model?
<lumag>
per family
<lumag>
aka_[m], also I suggest switching to #freedreno.
<aka_[m]>
*for
<aka_[m]>
Latest a5xx firmware probably ship on 439/429 devices
<aka_[m]>
Which is a505
<lumag>
I'm using firmware from linux-firmware, which corresponds to the latest db820c release
<lumag>
aka_[m], what is your SoC?
pevik has quit [Remote host closed the connection]
<aka_[m]>
lumag: 8976
<konradybcio>
a530 fw iirc
<konradybcio>
so you should be gtg with the linux-firmware one
<aka_[m]>
I can test a506/8953 tomorrow
<lumag>
aka_[m], please try with the latest fw from linux-firmware
<lumag>
The major difference that I see from A530 is the lack of GPMU, but I doubt that it matters
pevik has joined #linux-msm
abhinav__5 has joined #linux-msm
<konradybcio>
gpmu only did power rail stuff on a5xx, afaicr
<konradybcio>
so if it responds at all, it's "alive enough"
srinik has quit [Read error: Connection reset by peer]
srinik has joined #linux-msm
abhinav__ has quit [Ping timeout: 480 seconds]
<aka_[m]>
Latest is quite "dated"
<aka_[m]>
11.2017 that's very old
<konradybcio>
that sounds too old.. perhaps we should dig for something newer
<lumag>
konradybcio, ... and redistributable
<konradybcio>
let's check what sony open devices provided on 660
<konradybcio>
lumag: how would I check the fw version?
<konradybcio>
grepping for the git string gives nothing
<konradybcio>
ah no, it was the android libs that had a git string.. adreno fw had some magic bitfields..
<lumag>
konradybcio, I think the second dword is the version (the first dword being 0)
<lumag>
So we have 5ff08a for a530_pfp and 5ff063 for a530_pm4
<Marijn[m]>
bamse: now that I'm catching back up from hiatus: gentle poke for debugcc PRs :)
<lumag>
A note regarding versions: they are stored in little-endian, so you have to swap bytes to get the version
marvin24 has joined #linux-msm
<bamse>
Marijn[m]: why do you say that #17 depends on #15 and when i click that it contains the same MCCC for sm8150 and sm8250 commit?
<bamse>
Marijn[m]: ahh "referenced this pull request"
<Marijn[m]>
bamse: thanks for merging! Note that I still haven't figured out APCS on SM8250, was hoping for some feedback on that in parallel
<Marijn[m]>
bamse: 17 depends on 15/16
<bamse>
Marijn[m]: that part i understood, but i thought 15 contained the same patches as 17...because github is confusing
marvin24_ has quit [Ping timeout: 480 seconds]
<bamse>
hmm, no #17 has 6 commits...the first one is #15 :)
<bamse>
Marijn[m]: anyway, i merged #15 and #16, so now apparently you need to rebase #17 (?)
<Marijn[m]>
Rebased!
<Marijn[m]>
bamse: yes github sets up backreferences... When I mentioned "Depends on #15 and #16" in #17, you'd see in #15 and #16 that #17 is referencing them
<Marijn[m]>
As long as #17 is last (which it is!) everything is alright
Danct12 has joined #linux-msm
<bamse>
Marijn[m]: but i'm right in that it's telling me that i'm waiting for you to rebase and fix the conflicts, right?
<Marijn[m]>
bamse: Depends on when you looked :) - I rebased and pushed the results ±6 minutes ago
<Marijn[m]>
bamse: thanks! Yes would be great if we can finish konradybcio's series and get it in as well, and have a bunch of supported SoCs
<konradybcio>
on i
<konradybcio>
t
pevik_ has quit [Ping timeout: 480 seconds]
pevik__ has quit [Ping timeout: 480 seconds]
<Marijn[m]>
lumag: do you still need that register read for SM6125? It's 0x2004 so QSEED3LITE if the above is to be believed
<lumag>
Marijn[m], thanks!
<lumag>
so it seems that 3lite starts at sm7150 and ends before sm8250
<lumag>
e.g. only a part of DPU 5.x
<Marijn[m]>
lumag: also looking at `dpu_hw_setup_scaler3` it seems to deal with register values such as `scaler_version < 0x2004`, but the function is - as far as I can tell - called with the DPU_SSPP_SCALAR_QSEED* enum value that is just an integer set in the catalog...
<Marijn[m]>
Is that the bug you found?
<lumag>
kind of.
<lumag>
We had nearly everything telling that it is v3lite instead of v4
<Marijn[m]>
All of this looks fishy/broken... Don't get me started on how many typos one can cram into a single doc-comment block :(
<lumag>
Yep
<lumag>
I hope to get to resolving it in a clean way after landing catalog
<lumag>
I mean resolving v3 vs v3lite vs v4 in a sane way
<Marijn[m]>
lumag: I mean that the values are all out of sync
<Marijn[m]>
QSEED2 = 2, QSEED3 = 3, QSEED3LITE = 4, QSEED4 = 5 according to the enum... But that function expects the register value 0x2004
<lumag>
Hmm
<Marijn[m]>
0x2004 for QSEED3LITE*
<Marijn[m]>
Sorry, it takes the BIT() of those, but still BIT(4) isn't equal to 0x2004 :)
<lumag>
So, this goes back to original DPU commit
<Marijn[m]>
Unsurprisingly :)
<lumag>
Nice catch
<bamse>
konradybcio, Marijn[m]: do we have conclusion on the debugcc patch?
<Marijn[m]>
bamse: I'll test and go over the remaining review comments after my "shift" :)
<Marijn[m]>
lumag: do you want to fix it?
<bamse>
Marijn[m]: thanks!
abhinav__5 is now known as abhinav__
pespin has quit [Remote host closed the connection]
<lumag>
Marijn[m], no, feel free to fix it, or postpone for now
<lumag>
*feel free to fix it yourself, if you have time*
<lumag>
I think the easiest would be to keep the version checks in the dpu_hw_util.c
<Marijn[m]>
lumag: I haven't checked this in detail but will probably replace the comparisons of `scaler_version` against a register value with the bitflags in the `features` field
<Marijn[m]>
Would need to learn who 0x1002 is though
<Marijn[m]>
And it looks like get_scaler_ver and friends are dead code...
<konradybcio>
Marijn: maybe 8996? ill check
<Marijn[m]>
konradybcio: my 4.9 sources show that this field wasn't even initialized :)
<lumag>
0x1002 is 8998
<lumag>
Maybe
<lumag>
I checked on sdm660, that is has version 1.2