On Thu, Feb 2, 2012 at 4:19 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > Hi Rob, > > On Tuesday 31 January 2012 16:38:35 Clark, Rob wrote: >> 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.. > > On an embedded system putting the camera application in the background will > usually stop streaming, so buffers will be unmapped. On other systems, or even > on some embedded systems, that will not be the case though. > > I'm perfectly fine with relocating buffers when needed. What I want is to > avoid unmapping and remapping them for every frame if they haven't moved. I'm > sure we can come up with an API to handle that. > >> 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. > > It will likely depend on the camera hardware. For the OMAP3 ISP, the driver > calls the IOMMU API explictly, but if I understand it correctly there's a plan > to move IOMMU support to the DMA API. > >> 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? > > I see at least three possible solutions to this problem. > > 1. At dma_buf_unmap() time, the exporter will tell the importer that the > buffer will move, and that it should be unmapped from whatever the importer > mapped it to. That's probably the easiest solution to implement on the > importer's side, but I expect it to be difficult for the exporter to know at > dma_buf_unmap() time if the buffer will need to be moved or not. > > 2. Adding a callback to request the importer to unmap the buffer. This might > be racy, and locking might be difficult to handle. > > 3. At dma_buf_unmap() time, keep importer's mappings around. The exporter is > then free to move the buffer if needed, in which case the mappings will be > invalid. This shouldn't be a problem in theory, as the buffer isn't being used > by the importer at that time, but can cause stability issues when dealing with > rogue hardware as this would punch holes in the IOMMU fence. At dma_buf_map() > time the exporter would tell the importer whether the buffer moved or not. If > it moved, the importer will tear down the mappings it kept, and create new > ones. I was leaning towards door #3.. rogue hw is a good point, but I think that would be an issue in general if hw kept accessing the buffer when it wasn't supposed to. BR, -R > Variations around those 3 possible solutions are possible. > > -- > Regards, > > Laurent Pinchart -- 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
