On Fri, Mar 2, 2012 at 4:38 PM, Chris Wilson chris@chris-wilson.co.uk wrote:
On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter daniel.vetter@ffwll.ch wrote:
Big differences to other contenders in the field (like ion) is that this also supports highmem, so we have to split up the cpu access from the kernel side into a prepare and a kmap step.
Prepare is allowed to fail and should do everything required so that the kmap calls can succeed (like swapin/backing storage allocation, flushing, ...).
More in-depth explanations will follow in the follow-up documentation patch.
Changes in v2:
- Clear up begin_cpu_access confusion noticed by Sumit Semwal.
- Don't automatically fallback from the _atomic variants to the
non-atomic variants. The _atomic callbacks are not allowed to sleep, so we want exporters to make this decision explicit. The function signatures are explicit, so simpler exporters can still use the same function for both.
- Make the unmap functions optional. Simpler exporters with permanent
mappings don't need to do anything at unmap time.
Are we going to have to have a dma_buf->ops->begin_async_access(&me, dir) variant for coherency control of rendering with an imported dma_buf? There is also no concurrency control here between multiple importers doing simultaneous begin_cpu_access(). I presume that is going to be a common function across all exporters so the midlayer might offer a semaphore as a library function and then the dma_buf->ops->begin_cpu_access() becomes mandatory as at a minimum it has to point to the default implementation.
Initially the expectation was that userspace would not pass a buffer to multiple subsystems for writing (or that if it did, it would get the undefined results that one could expect).. so dealing w/ synchronization was punted.
I expect, though, that one of the next steps is some sort of sync-object mechanism to supplement dmabuf
BR, -R
-Chris
-- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html