From patchwork Wed Apr 20 17:13:28 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Harrison X-Patchwork-Id: 8893341 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id A2417BF440 for ; Wed, 20 Apr 2016 17:14:20 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 335962020F for ; Wed, 20 Apr 2016 17:14:18 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 58D45200D4 for ; Wed, 20 Apr 2016 17:14:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5AFFF6EA8C; Wed, 20 Apr 2016 17:14:12 +0000 (UTC) X-Original-To: Intel-GFX@lists.freedesktop.org Delivered-To: Intel-GFX@lists.freedesktop.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id 442906E231 for ; Wed, 20 Apr 2016 17:14:09 +0000 (UTC) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 20 Apr 2016 10:14:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,510,1455004800"; d="scan'208";a="689424356" Received: from johnharr-linux.isw.intel.com ([10.102.226.93]) by FMSMGA003.fm.intel.com with ESMTP; 20 Apr 2016 10:14:08 -0700 From: John.C.Harrison@Intel.com To: Intel-GFX@Lists.FreeDesktop.Org Date: Wed, 20 Apr 2016 18:13:28 +0100 Message-Id: <1461172435-4256-11-git-send-email-John.C.Harrison@Intel.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1461172435-4256-1-git-send-email-John.C.Harrison@Intel.com> References: <1461172435-4256-1-git-send-email-John.C.Harrison@Intel.com> Organization: Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ Subject: [Intel-gfx] [PATCH v6 10/34] drm/i915: Added scheduler hook into i915_gem_request_notify() X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: John Harrison The scheduler needs to know when requests have completed so that it can keep its own internal state up to date and can submit new requests to the hardware from its queue. v2: Updated due to changes in request handling. The operation is now reversed from before. Rather than the scheduler being in control of completion events, it is now the request code itself. The scheduler merely receives a notification event. It can then optionally request it's worker thread be woken up after all completion processing is complete. v4: Downgraded a BUG_ON to a WARN_ON as the latter is preferred. v5: Squashed the i915_scheduler.c portions down into the 'start of scheduler' patch. [Joonas Lahtinen] v6: Updated to newer nightly (lots of ring -> engine renaming). Changed an '|=' to an 'if() ='. [review feedback from Joonas Lahtinen] For: VIZ-1587 Signed-off-by: John Harrison Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index b7466cb..14dc641 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2918,6 +2918,7 @@ void i915_gem_request_notify(struct intel_engine_cs *engine, bool fence_locked) { struct drm_i915_gem_request *req, *req_next; unsigned long flags; + bool wake_sched = false; u32 seqno; if (list_empty(&engine->fence_signal_list)) { @@ -2956,6 +2957,15 @@ void i915_gem_request_notify(struct intel_engine_cs *engine, bool fence_locked) */ list_del_init(&req->signal_link); + /* + * NB: Must notify the scheduler before signalling + * the node. Otherwise the node can get retired first + * and call scheduler_clean() while the scheduler + * thinks it is still active. + */ + if (i915_scheduler_notify_request(req)) + wake_sched = true; + if (!req->cancelled) { fence_signal_locked(&req->fence); trace_i915_gem_request_complete(req); @@ -2972,6 +2982,13 @@ void i915_gem_request_notify(struct intel_engine_cs *engine, bool fence_locked) if (!fence_locked) spin_unlock_irqrestore(&engine->fence_lock, flags); + + /* Necessary? Or does the fence_signal() call do an implicit wakeup? */ + wake_up_all(&engine->irq_queue); + + /* Final scheduler processing after all individual updates are done. */ + if (wake_sched) + i915_scheduler_wakeup(engine->dev); } static const char *i915_gem_request_get_driver_name(struct fence *req_fence)