ChanServ changed the topic of #linux-msm to:
dliviu has quit [Ping timeout: 480 seconds]
dliviu has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
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> aka_[m], thanks for the report
<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
pevik_ has joined #linux-msm
<bamse> Marijn[m]: the button is green again :)
<bamse> konradybcio: afaict Marijn[m] has a comment/question on
<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
<lumag> And sdm845 is already 1.3
<lumag> 8996 is qseed2 if I remember correctly