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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F5F0C3F2D2 for ; Fri, 28 Feb 2020 15:15:06 +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 2259A24699 for ; Fri, 28 Feb 2020 15:15:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2259A24699 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 542A36F406; Fri, 28 Feb 2020 15:15:05 +0000 (UTC) Received: from fireflyinternet.com (mail.fireflyinternet.com [109.228.58.192]) by gabe.freedesktop.org (Postfix) with ESMTPS id 214626E065 for ; Fri, 28 Feb 2020 15:15:02 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 20386914-1500050 for multiple; Fri, 28 Feb 2020 15:15:00 +0000 MIME-Version: 1.0 From: Chris Wilson User-Agent: alot/0.6 To: Mika Kuoppala , intel-gfx@lists.freedesktop.org References: <20200228082330.2411941-1-chris@chris-wilson.co.uk> <20200228082330.2411941-18-chris@chris-wilson.co.uk> <87zhd27npz.fsf@gaia.fi.intel.com> In-Reply-To: <87zhd27npz.fsf@gaia.fi.intel.com> Message-ID: <158290289819.24106.3163488755084337083@skylake-alporthouse-com> Date: Fri, 28 Feb 2020 15:14:58 +0000 Subject: Re: [Intel-gfx] [PATCH 18/24] drm/i915/selftests: Wait for the kernel context switch X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Quoting Mika Kuoppala (2020-02-28 15:09:28) > Chris Wilson writes: > > > As we require a context switch to ensure that the current context is > > switched out and saved to memory, perform an explicit switch to the > > kernel context and wait for it. > > The patch subject is not incorrect. Just feels that the kernel > context is a patsy in here. > > So I would s/kernel// on subject but keep in commit msg > > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/gt/selftest_lrc.c | 37 +++++++++++++++++++------- > > 1 file changed, 28 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c b/drivers/gpu/drm/i915/gt/selftest_lrc.c > > index d7f98aada626..95da6b880e3f 100644 > > --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c > > +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c > > @@ -4015,6 +4015,31 @@ static int emit_semaphore_signal(struct intel_context *ce, void *slot) > > return 0; > > } > > > > +static int context_sync(struct intel_context *ce) > > +{ > > + struct i915_request *rq; > > + struct dma_fence *fence; > > + int err = 0; > > + > > + rq = intel_engine_create_kernel_request(ce->engine); > > + if (IS_ERR(rq)) > > + return PTR_ERR(rq); > > + > > + fence = i915_active_fence_get(&ce->timeline->last_request); > > + if (fence) { > > + i915_request_await_dma_fence(rq, fence); > > + dma_fence_put(fence); > > + } > > + > > + rq = i915_request_get(rq); > > + i915_request_add(rq); > > + if (i915_request_wait(rq, 0, HZ / 2) < 0) > > + err = -ETIME; > > + i915_request_put(rq); > > + > > + return err; > > +} > > + > > static int live_lrc_layout(void *arg) > > { > > struct intel_gt *gt = arg; > > @@ -4638,16 +4663,10 @@ static int __lrc_timestamp(const struct lrc_timestamp *arg, bool preempt) > > wmb(); > > } > > > > - if (i915_request_wait(rq, 0, HZ / 2) < 0) { > > - err = -ETIME; > > - goto err; > > - } > > - > > - /* and wait for switch to kernel */ > > - if (igt_flush_test(arg->engine->i915)) { > > - err = -EIO; > > + /* and wait for switch to kernel (to save our context to memory) */ > > + err = context_sync(arg->ce[0]); > > + if (err) > > goto err; > > - } > > > > rmb(); > > For me the context_sync could be context_flush and it would > allow the rmb() to be snuck inside. I hear you. The rmb() is really associated with the action of confirming the switch and can justifiably be inside the context_sync/flush. The rmb is just there to placate inner daemons, so I didn't think about it when forcing the emission of the kernel request. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx