ChanServ changed the topic of #linux-msm to:
falconhash[m] has joined #linux-msm
Danct12 has joined #linux-msm
srinik has quit [Quit: ZNC - http://znc.in]
srinik has joined #linux-msm
vkoul has quit [Quit: ZNC 1.7.2 - https://znc.in]
vkoul has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
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
<aka_[m]> [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=95, diff=0, hw=94 hw_last=94
<aka_[m]> Marijn: have you tried bringing a610 on trinket yet?
<Marijn[m]> We have DPU but I don't remember if we also started on the GPU
<aka_[m]> i tried on bengal and it crash with -19, some dts mention it uses zap shader however no region to be found
<aka_[m]> entry point says 0x5000
pespin has quit [Remote host closed the connection]
lumag_ has joined #linux-msm
lumag_ has quit [Remote host closed the connection]
lumag_ has joined #linux-msm
lumag_ has quit []
pevik has quit [Ping timeout: 480 seconds]
<aka_[m]> Any idea how to hit on a6xx gpu without GMU?
<aka_[m]> I added node but it appears to reboot
<aka_[m]> pstore is blank
<Mis012[m]> imho if gpu is needed for display out, that's a bug
<aka_[m]> so i was missing power-domains for GPU but even with them it reboot
<Mis012[m]> sa
<Mis012[m]> d
<aka_[m]> at first -19 so i think it was because i was lacking adreno smmu
<aka_[m]> so it was crying ENODEV
<aka_[m]> but cannot really find where it request iommu
<aka_[m]> Mis012: so i commented iommus and it fails but not reboot
jhovold has quit [Ping timeout: 480 seconds]
<Mis012[m]> does display care?
<aka_[m]> robclark: do a6xx_gpu.c by any chance assume every a6xx has LLCC?
<aka_[m]> There is bengal without LLCC
<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
<aka_[m]> already added
<aka_[m]> im bit too dumb to read drm.debug logs but its something like that:
qyousef has quit [Ping timeout: 480 seconds]
qyousef has joined #linux-msm
qyousef has quit [Ping timeout: 480 seconds]
qyousef has joined #linux-msm
qyousef has quit [Ping timeout: 480 seconds]