2016-07-12 6:59 GMT+09:00 Chris Wilson <chris at chris-wilson.co.uk>:
> When dealing with user interfaces that utilize explicit fences, it is
> convenient to sometimes create those fences after the fact, i.e. to
> query the dma-buf for the current set of implicit fences, encapsulate
> those into a sync_file and hand that fd back to userspace.
> Correspondingly, being able to add an explicit fence back into the mix
> of fences being tracked by the dma-buf allows that userspace fence to be
> included in any implicit tracking.
Regarding import fence, explicit fence can be corresponded to one of
sub-allocated blocks of a DMA buffer. What if user-space requested
import fence with a fence corresponding to a sub-allocated block?
As you know, implicit fence is always corresponded to one DMA buffer
not sub block of it. I guess there may be other things you should
consider for import fence interface.
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Gustavo Padovan <gustavo.padovan at collabora.co.uk>
> Cc: Rob Clark <robdclark at gmail.com>
> Cc: Sumit Semwal <sumit.semwal at linaro.org>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> Cc: dri-devel at lists.freedesktop.org
> ---
>
> Gustavo, could you look at the sync-file/fence-array handling? There's
> definitely room for a cleaner sync_file_create() API.
>
> I was thinking about this for the "why not sync-file" question Gustavo
> posed for the vgem_fences. I wanted to add an ioctl to the vgem to allow
> exporting and creating fences from sync-file for testing passing
> explicit userspaces around between drivers, and realised that I was just
> writing a generic mechanism that only required dma-buf.
>
> Whilst this interface could be used for lazily creating explicit fences,
> drivers will also likely want to support specific ioctl to skip the
> dmabuf creation, I think this interfaces will be useful with the vgem
> fences for testing sync_file handling in drivers (on i915 at the moment,
> my tests for sync_file involve sleeping and a few white lies). So
> fulfilling a similar role in driver testing to debugfs/sw_sync?
> (sw_sync is still more apt for testing timelines etc, vgem feels more
> apt for ease of testing rendering.)
> -Chris
>
> ---
> drivers/dma-buf/dma-buf.c | 100
> +++++++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/dma-buf.h | 9 ++++
> 2 files changed, 109 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 41fbce0c273a..6f066a8affd7 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -26,11 +26,13 @@
> #include <linux/slab.h>
> #include <linux/dma-buf.h>
> #include <linux/fence.h>
> +#include <linux/fence-array.h>
> #include <linux/anon_inodes.h>
> #include <linux/export.h>
> #include <linux/debugfs.h>
> #include <linux/module.h>
> #include <linux/seq_file.h>
> +#include <linux/sync_file.h>
> #include <linux/poll.h>
> #include <linux/reservation.h>
> #include <linux/mm.h>
> @@ -254,6 +256,97 @@ out:
> return events;
> }
>
> +static long dma_buf_import_fence_ioctl(struct dma_buf *dmabuf,
> + struct dma_buf_fence __user *arg)
> +{
> + struct reservation_object *resv = dmabuf->resv;
> + struct dma_buf_fence cmd;
> + struct fence *fence;
> + int ret;
> +
> + if (copy_from_user(&cmd, arg, sizeof(cmd)))
> + return -EFAULT;
> +
> + fence = NULL;
> + //fence = sync_file_get_fence(cmd.fd);
Your mistake?
Thanks,
Inki Dae
> + if (!fence)
> + return -EINVAL;
> +
