Am Donnerstag, den 24.05.2018, 10:43 +0200 schrieb Lucas Stach: > Hi Tomi, > > Am Donnerstag, den 24.05.2018, 11:39 +0300 schrieb Tomi Valkeinen: > > Hi Lucas, > > > > On 23/05/18 11:53, Lucas Stach wrote: > > > > > > With each run, I can see buffers being left lying around, > > > > visible > > > > in > > > > both omapdrm's and etnaviv's 'gem' debugfs file. And they're > > > > there > > > > even after killing X. > > > > > > > > If I try to rmmod etnaviv, I get the warnings below. Unloading > > > > omapdrm is not possible, as it's being referenced by something > > > > (presumably by etnaviv having imported omapdrm's dmabufs). > > > > > > > > I haven't debugged this much yet, but we do use dmabuf import & > > > > export successfully with omapdrm and v4l2. Has etnaviv dmabuf > > > > import/export been tested? > > > > > > Yes, dma-buf import/export with etnaviv is extensively being > > > used, > > > as > > > we need to work with imx-drm on the scanout side and a V4L2 > > > driven > > > VPU > > > for video-decode. > > > > I managed to create a simple test case for this, and I can see the > > leak > > happen without omapdrm too, with etna + vgem combination. > > > > https://github.com/tomba/kmsxx/blob/etna-debug/utils/buftest.cpp > > > > With etna_bo_map(), buffers leak. > > Thanks, this is really helpful! I'll have a look. Digging in it seems that etnaviv mmap is pretty broken for anything which isn't a etnaviv shm buffer. I'll get back to you once I have a patchset ready for test. Regards, Lucas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
