On Tue, Apr 15, 2025 at 03:57:11PM +0200, Christian König wrote: > Am 15.04.25 um 15:10 schrieb Simona Vetter: > >> This is for devices who only want to do a vmap of the buffer, isn't it? > > ... it's for the vmap only case, where you might not even have a struct > > device. Or definitely not a reasonable one, like maybe a faux_bus device > > or some device on a bus that really doesn't do dma (e.g. spi or i2c), and > > where hence dma_buf_map_attachment is just something you never ever want > > to do. > > Even in that case I would still suggest to at least create an attachment to > let the exporter know that somebody is doing something with it's buffer. > > That is also important for move notification since you can't do those without > an attachment. > > BTW: What is keeping a vmap alive after dropping the reservation lock? There > is no pinning whatsoever as far as I can see.
dma_buf_vmap should also pin, or something will go wrong very badly. And that also can tell the exporter what exactly the buffer is used for (kernel cpu access). I really don't think we should mix that up with device access as a dma_buf_attachment. -Sima > > > I think we might want to transform obj->import_attach into a union or > > tagged pointer or something like that, which can cover both cases. And > > maybe a drm_gem_bo_imported_dma_buf() helper that gives you the dma_buf no > > matter what if it's imported, or NULL if it's allocated on that > > drm_device? > > Yeah, I had the same idea before as well. Just didn't know if that was > something worth looking into. > > Regards, > Christian. > > > > > Cheers, Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
