<aka_[m]>
konradybcio: how good to have access to internal docs right
<aka_[m]>
even downstream call it qseed3lite
<konradybcio>
i mean, reading a register requires /dev/mem, not internal docs
<aka_[m]>
but 0x3 being qseed4
<aka_[m]>
thats weird
<konradybcio>
check 4.19 techpack
<konradybcio>
it's defined there
<konradybcio>
3lite is 0x2004
<aka_[m]>
meh
<aka_[m]>
konradybcio: i still remember downstream versioning of SAW2
<aka_[m]>
0x3 in register being 2.3 but having same layout like 3
<aka_[m]>
and 2.1 being different
<aka_[m]>
ehhh
<aka_[m]>
well that could work if we assume saw2 is "IP+Major" then 0x3 from register would place it as SAW2.3
<aka_[m]>
still why SAW4 on MSM8953 is 0x4xx1xx00
<lumag>
aka_[m], konradybcio yes. I was very puzzled with these version too, as you can see from the git history.
<konradybcio>
i will check 6375 in a couple minutes too
<lumag>
I think that might end up with 7150/6150/6125 for v3lite
<lumag>
unless 8150/c8180x are v3lite too
<konradybcio>
is there any good reason we hardcode it instead of reading the registers?
<lumag>
No, patches are welcome. I think we should declare QSEED3 (as opposed to QSEED2) and then determine 3/3lite/4 from register read
<konradybcio>
lumag: 6375 reads 0x00003000 as well
<lumag>
konradybcio, thanks!
<lumag>
konradybcio, I double-checked downstream. It has special quirks for qseed3, rev 1.2 (sdm660, maybe msm8998?), but doesn't have special name for that.
<konradybcio>
"fun"..
<aka_[m]>
that sounds so bad
<aka_[m]>
still 660 is running on MDP right
<lumag>
So, I think, we better handle this as a QSEED3 plus version checks
<lumag>
aka_[m], yes. Nobody had enough action points to finish and polish conversion from mdp5 to dpu1. Despite me having the actual board on my desk
<lumag>
The fun thing is that we agreed with robclark some time ago that together with the next conversion we will also introduce command line argument to toggle between mdp5 and dpu1. So it's not just about the catalog entry
<konradybcio>
lumag: well.. i did 2y ago :P
<konradybcio>
i think i should have it on some branch somewhere
<lumag>
Yes, I even saw that once
<lumag>
But I don't remember why nobody pushed it out.
<lumag>
That's why I said 'finish and polish'.
<konradybcio>
i was busy with the 70 patches long 660 series, probably
<konradybcio>
:D
<lumag>
Most likely
svarbanov_ has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
amnesia163 has joined #linux-msm
minecrell has quit [Quit: :( ]
minecrell has joined #linux-msm
amnesia163 has quit []
<Leandro[m]>
<lumag> "Leandro, I'd say, start really..." <- i hear uart my brain goes bwom
<Leandro[m]>
s/bwom/bwomp/
<vknecht[m]>
don't sweat on uart, if you're able to get usb working without it you're good to go too :-)
pevik_ has quit [Quit: Reconnecting]
pevik_ has joined #linux-msm
pevik__ has joined #linux-msm
pevik__ has quit [Ping timeout: 480 seconds]
pevik_ has quit [Ping timeout: 480 seconds]
<aka_[m]>
lumag: have you tested 660 lately?
<aka_[m]>
This bug with rings probably affects all adreno 5xx right
<gpiccoli>
Folks, being facing an issue here..I have a patch ready but wants to validate first. I tried to build the dt blog with skales-dtbtool, it fails..I've narrowed down to an issue with a new dts missing qcom,msm-id. Adding that, it works. Is it a correct fix?
<gpiccoli>
it's msm8996-based
<gpiccoli>
tnx in advance!
<konradybcio>
does this concern a device that's currently supported upstream? gpiccoli
<gpiccoli>
konradybcio, I think it's supported upstream - oneplus3t <- it's on tree
<gpiccoli>
the only thing is that I'm far from expert on DT, and seeing "deprecated:yes" on the qcom,msm-id makes me a little dubious on adding it...
<gpiccoli>
heh
pespin has quit []
<gpiccoli>
but with my patch dtbtool works fine!
<konradybcio>
looks like OP3 sets it, but OP3T doesn't
<konradybcio>
so it was probably overlooked
<gpiccoli>
yeah, exactly
<gpiccoli>
cool! so gonna send that, thanks! I'll CC you on that konradybcio , appreciate the help =)
svarbanov_ has joined #linux-msm
svarbanov has quit [charon.oftc.net kinetic.oftc.net]
sergi has quit [charon.oftc.net kinetic.oftc.net]
FieryFlames[m] has quit [charon.oftc.net kinetic.oftc.net]
fevv8[m] has quit [charon.oftc.net kinetic.oftc.net]
ungeskriptet has quit [charon.oftc.net kinetic.oftc.net]
Leandro[m] has quit [charon.oftc.net kinetic.oftc.net]
ichernev[m] has quit [charon.oftc.net kinetic.oftc.net]
JIaxyga[m] has quit [charon.oftc.net kinetic.oftc.net]
kholk[m] has quit [charon.oftc.net kinetic.oftc.net]
ywmaadev5[m] has quit [charon.oftc.net kinetic.oftc.net]
Marijn[m] has quit [charon.oftc.net kinetic.oftc.net]
mothenjoyer69 has quit [charon.oftc.net kinetic.oftc.net]
Mis012[m] has quit [charon.oftc.net kinetic.oftc.net]
vknecht[m] has quit [charon.oftc.net kinetic.oftc.net]
jojo_autoboy[m] has quit [charon.oftc.net kinetic.oftc.net]
Tooniis[m] has quit [charon.oftc.net kinetic.oftc.net]
undev[m] has quit [charon.oftc.net kinetic.oftc.net]
peremen[m] has quit [charon.oftc.net kinetic.oftc.net]
AffeNull[m] has quit [charon.oftc.net kinetic.oftc.net]
ivoszbg[m] has quit [charon.oftc.net kinetic.oftc.net]
Newbyte has quit [charon.oftc.net kinetic.oftc.net]
dv_ has quit [charon.oftc.net kinetic.oftc.net]
DavidHeidelberg[m] has quit [charon.oftc.net kinetic.oftc.net]