On Sun, Jan 15, 2012 at 2:08 AM, Sakari Ailus sakari.ailus@iki.fi wrote:
Hi Sumit,
Thanks for the patch!
Hi Sakari,
Thanks for reviewing this :)
<snip> Shouldn't the buffer mapping only be done at the first call to __qbuf_dmabuf()? On latter calls, the cache would need to be handled according to presence of V4L2_BUF_FLAG_NO_CACHE_CLEAN / V4L2_BUF_FLAG_NO_CACHE_INVALIDATE in v4l2_buffer.
Well, the 'map / unmap' implementation is by design exporter-specific; so the exporter of the buffer may choose to, depending on the use case, 'map-and-keep' on first call to map_dmabuf, and do actual unmap only at 'release' time. This will mean that the {map,unmap}_dmabuf calls will be used mostly for 'access-bracketing' between multiple users, and not for actual map/unmap each time. Again, the framework is flexible enough to allow exporters to actually map/unmap as required (think cases where backing-storage migration might be needed while buffers are in use - in that case, when all current users have called unmap_XXX() on a buffer, it can be migrated, and the next map_XXX() calls could give different mappings back to the users). The kernel 'users' of dma-buf [in case of this RFC, v4l2] should not ideally need to worry about the actual mapping/unmapping that is done; the buffer exporter in a particular use-case should be able to handle it. <snip>
Same here, except reverse: this only should be done when the buffer is destroyed --- either when the user explicitly calls reqbufs(0) or when the file handle owning this buffer is being closed.
Mapping buffers at every prepare_buf and unmapping them in dqbuf is prohibitively expensive. Same goes for many other APIs than V4L2, I think.
I wonder if the means to do this exists already.
I have to admit I haven't followed the dma_buf discussion closely so I might be missing something relevant here.
Hope the above explanation helps. Please do not hesitate to contact if you need more details.
Kind regards,
-- Sakari Ailus sakari.ailus@iki.fi
Best regards, ~Sumit.