Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
pespin has joined #linux-msm
jhovold has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
<aka_[m]>
Marijn: not sure but is amount of vblanks fired main issue there?
<aka_[m]>
I don't see them in that amount on 7125
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
pevik has joined #linux-msm
Danct12 has quit [Remote host closed the connection]
svarbanov has joined #linux-msm
Danct12 has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
svarbanov has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
<Marijn[m]>
aka_: Where do you see an "amount" of vblanks being fired?
<Marijn[m]>
Keep in mind that there is typically a vsync line going from the panel to the board, letting the DPU (the pingpong block, AFAIR) know when it is ready for the next frame / finished presenting the current frame
<Marijn[m]>
Make sure you're turning that on with a DCS command 😬
<aka_[m]>
<Marijn[m]> "aka_: Where do you see an "..." <- it keeps saying "increase count"
<aka_[m]>
up to 186 or something
<aka_[m]>
i have changed dpu caps because somehow i used qcm2290 linewidth which says 2160 and panel i use is 2340 and limits for vig(?) says 2560
<aka_[m]>
tho not sure about mixer because downstream says 2048 for both qcm2290/bengal but qcm2290 has it defined as 2560
<robclark>
it at least hasn't been tested on any device w/out LLCC that I am aware of
<aka_[m]>
quite sad
<aka_[m]>
bengal/trinket/khaje are ones without llcc
<aka_[m]>
662/665/680
<robclark>
patches welcome ;-)
<robclark>
aka_[m]: fwiw, we had a6xx running for a quite a while before llcc was supported upstream.. so if it doesn't work on devices without llcc then it should only be trivial fixes
<aka_[m]>
im not exactly up to the task xD
<aka_[m]>
i know somewhere after it probably goes for iommu it die
<aka_[m]>
a610 has no gmu so maybe it needs some special care
<aka_[m]>
im still quite stuck with blank output from dpu...
<robclark>
not having gmu is probably a much more significant challenge
<robclark>
gpu doesn't even try to load until you have rootfs (and it can load it's firmware files).. so you are probably not even getting as far as gpu stuff yet
<aka_[m]>
it just do something then goes straight to cleanup after printing revision
<robclark>
with bootloader leaving the display enabled, there are some workarounds needed on arm-smmu-qcom.c .. basically you'll need to add your device to a list of compatible strings in there to tell arm-smmu to not fiddle with things and break display
<robclark>
if it gets to point of trying to load gpu, probably bails if no gmu device? The no-gmu config is completely unsupported
<aka_[m]>
just cleanup and nothing more in log
<aka_[m]>
after i added iommu it reboots
<aka_[m]>
otherwise it was doing ENODEV
<aka_[m]>
sm6115 dpu is very similar to qcm2290 but im not sure if it works just like that without additonal patches
<aka_[m]>
on mdss front i added compatible "qcom,sm6115-mdss"
<aka_[m]>
logs says it does some stuff but as long as it not show anything its not really anything worth mentioning
<aka_[m]>
sm6115 dpu is very similar to qcm2290 but im not sure if it works just like that without additonal patches
<aka_[m]>
* on mdss front i added compatible "qcom,sm6115-mdss" to arm-smmu-qcom
<robclark>
I think you probably also need to update qcom_smmu_impl_of_match[] ... maybe that isn't needed yet
<robclark>
defn need display compat in qcom_smmu_client_of_match