Rendering operations to the dma-buf are tracked implicitly via the
reservation_object (dmabuf->resv). This is used to allow poll() to
wait upon outstanding rendering (or just query the current status of
rendering). The dma-buf sync ioctl allows userspace to prepare the
dma-buf for CPU access, which should include waiting upon rendering.
(Some drivers may need to do more work to ensure that the dma-buf mmap
is coherent as well as complete.)
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: linux-media(a)vger.kernel.org
Cc: dri-devel(a)lists.freedesktop.org
Cc: linaro-mm-sig(a)lists.linaro.org
Cc: linux-kernel(a)vger.kernel.org
---
I'm wondering whether it makes sense just to always do the wait first.
It is one of the first operations every driver has to make. A driver
that wants to implement it differently (e.g. they can special case
native waits) will still require a wait on the reservation object to
finish external rendering.
-Chris
---
drivers/dma-buf/dma-buf.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ddaee60ae52a..123f14b8e882 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
+static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+ enum dma_data_direction direction)
+{
+ bool write = (direction == DMA_BIDIRECTIONAL ||
+ direction == DMA_TO_DEVICE);
+ struct reservation_object *resv = dma_buf->resv;
+ long ret;
+
+ /* Wait on any implicit rendering fences */
+ ret = reservation_object_wait_timeout_rcu(resv, write, true,
+ MAX_SCHEDULE_TIMEOUT);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
/**
* dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from the
@@ -607,6 +623,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
if (dmabuf->ops->begin_cpu_access)
ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
+ else
+ ret = __dma_buf_begin_cpu_access(dmabuf, direction);
return ret;
}
--
2.8.1
Hi,
At LPC, I proposed a moratorium on new Ion features because of issues
preventing Ion ever moving out of staging. Among other problems,
the Ion caching model hasn't made much progress to a solution that
is widely accepted and there are still problems with devicetree
support. There were no strong objections to this proposal so I
propose continuing with a moratorium for at least the next 6 months
to a year to actually work on a new architecture. If this hasn't
made much progress by then I plan to hand off Ion to someone else
to try other approaches.
There's been some discussion about a Unix Device Memory Allocator
https://github.com/cubanismo/allocator . Ideally, this would be
a complete replacement for Ion. This means capturing Ion or
Ion-like requirements. The current proposal mostly focuses on
userspace requirements and assumes Ion is just acting as an
enumerator of various memory to allocate. This is a good direction.
Ideally some of the Ion kernel code could be leveraged for a 'generic
device memory allocator'. This device allocator should also be
support use cases such as the SMAF (secure memory allocation
framework) which has also been a work in progress.
One of the big open problems, as mentioned above, is the caching
model. Specifying an uncached buffer at allocation time requires
doing cache operations outside of the DMA framework which makes
a bunch of maintainers unhappy. None of the arguments I've given
for justification have really stuck which is a good sign that Ion
should probably not be doing cache operations. If we ignore the Ion
page pooling feature, this could be fixed by requiring that drivers
call dma_buf_map and calling dma_map there. This gets tricker when
drivers want to call mmap from userspace before passing the buffer
down to ensure coherency. This model will need some more thought
and possibly integration with Android.
I'd like to keep using linaro-mm-sig as a mailing list for Ion
discussion as well as drivers-devel. If it would help to have
another place for tracking/discussion I can see about setting
that up as well.
Thanks,
Laura
