ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
pcercuei_ has quit []
robertfoss has quit [Ping timeout: 480 seconds]
tchebb has joined #etnaviv
tchebb_ has quit [Ping timeout: 480 seconds]
robertfoss has joined #etnaviv
tchebb_ has joined #etnaviv
tchebb has quit [Ping timeout: 480 seconds]
tchebb has joined #etnaviv
tchebb_ has quit [Ping timeout: 480 seconds]
mvlad has joined #etnaviv
robertfoss has quit [Ping timeout: 480 seconds]
frieder has joined #etnaviv
tchebb_ has joined #etnaviv
tchebb has quit [Ping timeout: 480 seconds]
robertfoss has joined #etnaviv
lynxeye has joined #etnaviv
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #etnaviv
frieder has quit [Remote host closed the connection]
frieder has joined #etnaviv
sravn has quit [Remote host closed the connection]
sravn has joined #etnaviv
pcercuei has joined #etnaviv
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #etnaviv
f_ has joined #etnaviv
f_ has quit [Quit: To contact me, PM f_[xmpp] or send an email. See https://vitali64.duckdns.org/.]
f_ has joined #etnaviv
frieder has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
f_ has quit [Quit: To contact me, PM f_[xmpp] or send an email. See https://vitali64.duckdns.org/.]
cphealy has joined #etnaviv
mvlad has quit [Remote host closed the connection]
<bl4ckb0ne> do I need to do something in particular to get `viv_interpose.so`? following libvivhook's README gives `viv_interpose.la` only
<austriancoder> bl4ckb0ne: it should work as written in the readme
<bl4ckb0ne> might be my cross compile setup hm
<austriancoder> bl4ckb0ne: btw do you also see lot of "swiotlb buffer is full" messages around mmu faults?
<bl4ckb0ne> nope
<austriancoder> bl4ckb0ne: mind sharing your dts?
<bl4ckb0ne> i see a log message about gpu idle with 6.1 around the hang
<austriancoder> bl4ckb0ne: for me kmscube seems to work fine (with vkms)
<bl4ckb0ne> havent tried kmscube yet, will give a go
<bl4ckb0ne> i dont think I can share the dts sorry
<austriancoder> bl4ckb0ne: anything special in the dts about reserved memory .. maybe GPU related?
<bl4ckb0ne> i can take a look
<ManMower> gpu_reserved: gpu_reserved@0x8800000000 { no-map; reg = <0x8 0x80000000 0 0x20000000>;
<ManMower> };
<ManMower> (answering on behalf of bl4ckb0ne with a really sketchy cut and paste...)
<ManMower> there's a linux,cma section as well, is that relevant?
<austriancoder> DDR on the imx8qm starts at 0x880000000 and there are some mmu limitations: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/etnaviv/etnaviv_drv.c?h=v6.9-rc7#n623
<austriancoder> looks like there is an other ddr addres in the reference manual: 0x80000000
samuelig has joined #etnaviv
<ManMower> is our dts wrong/bad?
<austriancoder> That gpu_reserved label is used in galore driver (in downstream kernel). etnaviv does nothing with it
<austriancoder> I know that the userspace part runs without problems on that SoC. So I would focus on this gpu_reserved label.
samuelig has quit [Quit: Bye!]
<bl4ckb0ne> austriancoder: lynxeye told us that the userspace might not set an address register properly and that could cause the mmu fault
<austriancoder> bl4ckb0ne: that's the generic answer why there is an mmu fault with address 0x0. Look at the generated cmd stream and search for a 0x0.
<austriancoder> bl4ckb0ne: kmscube works for you?
<bl4ckb0ne> havent tried, cooking dinner
<bl4ckb0ne> will do later
<austriancoder> bl4ckb0ne: k..
<austriancoder> bl4ckb0ne: from a hwdb view I see no reason why the cmd stream should be that different to the other gc7000.
<austriancoder> Bed time here..
<bl4ckb0ne> have a good one, ill update the chan tonight