On 2 February 2012 19:31, Clark, Rob rob@ti.com wrote:
On Thu, Feb 2, 2012 at 4:19 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com 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@iki.fi 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.
- 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.
- Adding a callback to request the importer to unmap the buffer. This might
be racy, and locking might be difficult to handle.
- 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.
Yes, I feel #3 is a fair way of solving this.
BR, -R
Variations around those 3 possible solutions are possible.
-- Regards,
Laurent Pinchart
Thanks and regards, ~Sumit.