On Mon, Jan 30, 2012 at 4:01 PM, Sakari Ailus <sakari.ailus@xxxxxx> wrote: > >> So to summarize I understand your constraints - gpu drivers have worked >> like v4l a few years ago. The thing I'm trying to achieve with this >> constant yelling is just to raise awereness for these issues so that >> people aren't suprised when drm starts pulling tricks on dma_bufs. > > I think we should be able to mark dma_bufs non-relocatable so also DRM can > work with these buffers. Or alternatively, as Laurent proposed, V4L2 be > prepared for moving the buffers around. Are there other reasons to do so > than paging them out of system memory to make room for something else? fwiw, from GPU perspective, the DRM device wouldn't be actively relocating buffers just for the fun of it. I think it is more that we want to give the GPU driver the flexibility to relocate when it really needs to. For example, maybe user has camera app running, then puts it in the background and opens firefox which tries to allocate a big set of pixmaps putting pressure on GPU memory.. I guess the root issue is who is doing the IOMMU programming for the camera driver. I guess if this is something built in to the camera driver then when it calls dma_buf_map() it probably wants some hint that the backing pages haven't moved so in the common case (ie. buffer hasn't moved) it doesn't have to do anything expensive. On omap4 v4l2+drm example I have running, it is actually the DRM driver doing the "IOMMU" programming.. so v4l2 camera really doesn't need to care about it. (And the IOMMU programming here is pretty fast.) But I suppose this maybe doesn't represent all cases. I suppose if a camera didn't really sit behind an IOMMU but uses something more like a DMA descriptor list would want to know if it needed to regenerate it's descriptor list. Or likewise if camera has an IOMMU that isn't really using the IOMMU framework (although maybe that is easier to solve). But I think a hint returned from dma_buf_map() would do the job? BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
