On Thu, Feb 2, 2012 at 2:23 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Feb 2, 2012 at 11:19, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
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.
Variations around those 3 possible solutions are possible.
While preparing my fosdem presentation about dma_buf I've thought quite a bit what we still need for forceful unmap support/persistent mappings/dynamic dma_buf/whatever you want to call it. And it's a lot, and we have quite a few lower hanging fruits to reap (like cpu access and mmap support for importer). So I propose instead:
- Just hang onto the device mappings for as long as it's convenient and/or
necessary and feel guilty about it.
for v4l2/vb2, I'd like to at least request some sort of BUF_PREPARE_IS_EXPENSIVE flag, so we don't penalize devices where remapping is not expensive. Ie. the camera driver could set this flag so vb2 core knows not unmap()/re-map() between frames.
In my case, for v4l2 + encoder, I really need the unmapping/remapping between frames, at least if there is anything else going on competing for buffers. But in my case, the exporter remaps to a contiguous (sorta) "virtual" address that the camera can see, so there is no expensive mapping on the importer side of things.
BR, -R
The reason is that going fully static isn't worse than a half-baked dynamic version of dma_buf, but the half-baked dynamic one has the downside that we can ignore the issue and feel good about things ;-)
Cheers, Daniel
Daniel Vetter daniel.vetter@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch