[PATCH 2/4] drm/vc4: Syncobj import support
Eric Anholt
eric at anholt.net
Mon Apr 23 11:59:37 PDT 2018
Stefan Schake <stschake at gmail.com> writes:
> Allow userland to specify a syncobj that is waited on before a render job
> starts processing.
>
> Signed-off-by: Stefan Schake <stschake at gmail.com>
> ---
> drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
> drivers/gpu/drm/vc4/vc4_gem.c | 33 +++++++++++++++++++++++++++------
> include/uapi/drm/vc4_drm.h | 9 +++++----
> 3 files changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 4288615b66a2..3105df99cb12 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -10,6 +10,8 @@
> #include <drm/drmP.h>
> #include <drm/drm_encoder.h>
> #include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_syncobj.h>
> +
Drop the extra \n?
> #include "uapi/drm/vc4_drm.h"
>
> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index 2107b0daf8ef..232363488125 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -27,6 +27,7 @@
> #include <linux/device.h>
> #include <linux/io.h>
> #include <linux/sched/signal.h>
> +#include <linux/dma-fence-array.h>
>
> #include "uapi/drm/vc4_drm.h"
> #include "vc4_drv.h"
> @@ -1115,21 +1116,18 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
> struct drm_vc4_submit_cl *args = data;
> struct vc4_exec_info *exec;
> struct ww_acquire_ctx acquire_ctx;
> + struct dma_fence *in_fence;
> int ret = 0;
>
> if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
> VC4_SUBMIT_CL_FIXED_RCL_ORDER |
> VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
> - VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y)) != 0) {
> + VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y |
> + VC4_SUBMIT_CL_IMPORT_SYNCOBJ)) != 0) {
> DRM_DEBUG("Unknown flags: 0x%02x\n", args->flags);
> return -EINVAL;
> }
>
> - if (args->pad2 != 0) {
> - DRM_DEBUG("->pad2 must be set to zero\n");
> - return -EINVAL;
> - }
> -
> exec = kcalloc(1, sizeof(*exec), GFP_KERNEL);
> if (!exec) {
> DRM_ERROR("malloc failure on exec struct\n");
> @@ -1164,6 +1162,29 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
> }
> }
>
> + if (args->flags & VC4_SUBMIT_CL_IMPORT_SYNCOBJ) {
> + ret = drm_syncobj_find_fence(file_priv, args->in_sync,
> + &in_fence);
> + if (ret)
> + goto fail;
> +
> + /* When the fence (or fence array) is exclusively from our
> + * context we can skip the wait since jobs are executed in
> + * order of their submission through this ioctl and this can
> + * only have fences from a prior job.
> + */
> + if (!dma_fence_match_context(in_fence,
> + vc4->dma_fence_context)) {
> + ret = dma_fence_wait(in_fence, true);
> + if (ret) {
> + dma_fence_put(in_fence);
> + goto fail;
> + }
> + }
> +
> + dma_fence_put(in_fence);
> + }
I don't think we need an extra flag here. 0 is an invalid syncobj
handle, so that could be the indication that there's no input syncobj.
Long term, we should probably only block once we're ready to exec the
job, not at submit time. However, I think we can wait on fixing that
until we start using the GPU scheduler.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20180423/4c8db45f/attachment.sig>
More information about the linux-rpi-kernel
mailing list