From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0A9CC433F5 for ; Mon, 4 Oct 2021 12:24:31 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7242361159 for ; Mon, 4 Oct 2021 12:24:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7242361159 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 953D56E131; Mon, 4 Oct 2021 12:24:30 +0000 (UTC) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by gabe.freedesktop.org (Postfix) with ESMTPS id 340086E131 for ; Mon, 4 Oct 2021 12:24:29 +0000 (UTC) Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 6306E1F434B2; Mon, 4 Oct 2021 13:24:27 +0100 (BST) Date: Mon, 4 Oct 2021 14:24:24 +0200 From: Boris Brezillon To: Steven Price Cc: Rob Herring , Tomeu Vizoso , Alyssa Rosenzweig , Robin Murphy , dri-devel@lists.freedesktop.org, Daniel Vetter , Jason Ekstrand , Daniel Stone , Christian =?UTF-8?B?S8O2bmln?= Subject: Re: [PATCH v5 6/8] drm/panfrost: Support synchronization jobs Message-ID: <20211004142424.09afb418@collabora.com> In-Reply-To: <9ed27061-54f3-1804-936d-18aecf3d8872@arm.com> References: <20210930190954.1525933-1-boris.brezillon@collabora.com> <20210930190954.1525933-7-boris.brezillon@collabora.com> <9ed27061-54f3-1804-936d-18aecf3d8872@arm.com> Organization: Collabora X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, 4 Oct 2021 12:30:42 +0100 Steven Price wrote: > On 30/09/2021 20:09, Boris Brezillon wrote: > > Sometimes, all the user wants to do is add a synchronization point. > > Userspace can already do that by submitting a NULL job, but this implies > > submitting something to the GPU when we could simply skip the job and > > signal the done fence directly. > > > > v5: > > * New patch > > > > Signed-off-by: Boris Brezillon > > I had thought we would be fine without kbase's "dependency only atom" > because we don't have the fan-{in,out} problems that kbase's atoms > produce. But if we're ending up with real hardware NULL jobs then this > is clearly better. > > A couple of minor points below, but as far as I can tell this is > functionally correct. > > Reviewed-by: Steven Price > > > --- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 9 +++++++-- > > drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++++++ > > include/uapi/drm/panfrost_drm.h | 7 +++++++ > > 3 files changed, 20 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c > > index 30dc158d56e6..89a0c484310c 100644 > > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c > > @@ -542,7 +542,9 @@ static const struct panfrost_submit_ioctl_version_info submit_versions[] = { > > [1] = { 48, 8, 16 }, > > }; > > > > -#define PANFROST_JD_ALLOWED_REQS PANFROST_JD_REQ_FS > > +#define PANFROST_JD_ALLOWED_REQS \ > > + (PANFROST_JD_REQ_FS | \ > > + PANFROST_JD_REQ_DEP_ONLY) > > > > static int > > panfrost_submit_job(struct drm_device *dev, struct drm_file *file_priv, > > @@ -559,7 +561,10 @@ panfrost_submit_job(struct drm_device *dev, struct drm_file *file_priv, > > if (args->requirements & ~PANFROST_JD_ALLOWED_REQS) > > return -EINVAL; > > > > - if (!args->head) > > + /* If this is a dependency-only job, the job chain head should be NULL, > > + * otherwise it should be non-NULL. > > + */ > > + if ((args->head != 0) != !(args->requirements & PANFROST_JD_REQ_DEP_ONLY)) > > NIT: There's confusion over NULL vs 0 here - the code is correct > (args->head is a u64 and not a pointer for a kernel) but the comment > makes it seem like it should be a pointer. > > We could side-step the mismatch by rewriting as below: > > !args->head == !(args->requirements & PANFROST_JD_REQ_DEP_ONLY) > > Although I'm not convinced whether that's more readable or not! I'll replace 'NULL' by 'zero' in the comment. > > > return -EINVAL; > > > > bo_stride = submit_versions[version].bo_ref_stride; > > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c > > index 0367cee8f6df..6d8706d4a096 100644 > > --- a/drivers/gpu/drm/panfrost/panfrost_job.c > > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > > @@ -192,6 +192,12 @@ static void panfrost_job_hw_submit(struct panfrost_job *job, int js) > > u64 jc_head = job->jc; > > int ret; > > > > + if (job->requirements & PANFROST_JD_REQ_DEP_ONLY) { > > + /* Nothing to execute, signal the fence directly. */ > > + dma_fence_signal_locked(job->done_fence); > > + return; > > + } > > + > > It took me a while to convince myself that the reference counting for > the PM reference is correct. Before panfrost_job_hw_submit() always > returned with an extra reference, but now we have a case which doesn't. > AFAICT this is probably fine because we dereference on the path where > the hardware has completed the job (which obviously won't happen here). > But I'm still a bit uneasy whether the reference counts are always correct. I think it is. We only decrement the PM count in the interrupt handler path, and as you pointed out, we won't reach that path here. But if that helps, I can move this if to `panfrost_job_run()`: /* Nothing to execute, signal the fence directly. */ if (job->requirements & PANFROST_JD_REQ_DEP_ONLY) dma_fence_signal_locked(job->done_fence); else panfrost_job_hw_submit(job, slot); > > Steve > > > panfrost_devfreq_record_busy(&pfdev->pfdevfreq); > > > > ret = pm_runtime_get_sync(pfdev->dev); > > diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h > > index 5e3f8a344f41..b9df066970f6 100644 > > --- a/include/uapi/drm/panfrost_drm.h > > +++ b/include/uapi/drm/panfrost_drm.h > > @@ -46,6 +46,13 @@ extern "C" { > > #define DRM_IOCTL_PANFROST_PERFCNT_DUMP DRM_IOW(DRM_COMMAND_BASE + DRM_PANFROST_PERFCNT_DUMP, struct drm_panfrost_perfcnt_dump) > > > > #define PANFROST_JD_REQ_FS (1 << 0) > > + > > +/* > > + * Dependency only job. The job chain head should be set to 0 when this flag > > + * is set. > > + */ > > +#define PANFROST_JD_REQ_DEP_ONLY (1 << 1) > > + > > /** > > * struct drm_panfrost_submit - ioctl argument for submitting commands to the 3D > > * engine. > > >