From patchwork Tue Feb 27 12:52:22 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Micha=C5=82_Winiarski?= X-Patchwork-Id: 10245101 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id D20E560362 for ; Tue, 27 Feb 2018 12:54:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C4604288BE for ; Tue, 27 Feb 2018 12:54:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B8F9B288C6; Tue, 27 Feb 2018 12:54:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 66637288BE for ; Tue, 27 Feb 2018 12:54:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AD73C6E662; Tue, 27 Feb 2018 12:54:31 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id C6F446E662 for ; Tue, 27 Feb 2018 12:54:29 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2018 04:54:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,400,1515484800"; d="scan'208";a="30083937" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by FMSMGA003.fm.intel.com with ESMTP; 27 Feb 2018 04:54:28 -0800 Received: from localhost (172.28.172.64) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 27 Feb 2018 12:54:28 +0000 From: =?UTF-8?q?Micha=C5=82=20Winiarski?= To: Date: Tue, 27 Feb 2018 13:52:22 +0100 Message-ID: <20180227125230.13000-7-michal.winiarski@intel.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180227125230.13000-1-michal.winiarski@intel.com> References: <20180227125230.13000-1-michal.winiarski@intel.com> MIME-Version: 1.0 X-Originating-IP: [172.28.172.64] Subject: [Intel-gfx] [PATCH 07/15] drm/i915/guc: Flush directly in log unregister X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP Having both guc_flush_logs and guc_log_flush functions is confusing. While we could just rename things, guc_flush_logs implementation is quite simple. Let's get rid of it and move its content to unregister. Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble Cc: Michal Wajdeczko Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_guc_log.c | 35 +++++++++++++++-------------------- 1 file changed, 15 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index cbbdb400fa17..0800c5317510 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -443,25 +443,6 @@ static void guc_log_capture_logs(struct intel_guc *guc) intel_runtime_pm_put(dev_priv); } -static void guc_flush_logs(struct intel_guc *guc) -{ - struct drm_i915_private *dev_priv = guc_to_i915(guc); - - /* - * Before initiating the forceful flush, wait for any pending/ongoing - * flush to complete otherwise forceful flush may not actually happen. - */ - flush_work(&guc->log.runtime.flush_work); - - /* Ask GuC to update the log buffer state */ - intel_runtime_pm_get(dev_priv); - guc_log_flush(guc); - intel_runtime_pm_put(dev_priv); - - /* GuC would have updated log buffer by now, so capture it */ - guc_log_capture_logs(guc); -} - int intel_guc_log_create(struct intel_guc *guc) { struct i915_vma *vma; @@ -628,14 +609,28 @@ int intel_guc_log_register(struct intel_guc *guc) void intel_guc_log_unregister(struct intel_guc *guc) { + struct drm_i915_private *dev_priv = guc_to_i915(guc); + guc_log_flush_irq_disable(guc); + + /* + * Before initiating the forceful flush, wait for any pending/ongoing + * flush to complete otherwise forceful flush may not actually happen. + */ + flush_work(&guc->log.runtime.flush_work); + /* * Once logging is disabled, GuC won't generate logs & send an * interrupt. But there could be some data in the log buffer * which is yet to be captured. So request GuC to update the log * buffer state and then collect the left over logs. */ - guc_flush_logs(guc); + intel_runtime_pm_get(dev_priv); + guc_log_flush(guc); + intel_runtime_pm_put(dev_priv); + + /* GuC would have updated log buffer by now, so capture it */ + guc_log_capture_logs(guc); mutex_lock(&guc->log.runtime.lock);