From patchwork Thu Sep 8 10:39:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: akash.goel@intel.com X-Patchwork-Id: 9320911 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 7262B60231 for ; Thu, 8 Sep 2016 10:26:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5685629785 for ; Thu, 8 Sep 2016 10:26:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4B852297A0; Thu, 8 Sep 2016 10:26:15 +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 BD4CC29785 for ; Thu, 8 Sep 2016 10:26:12 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DEE706EE13; Thu, 8 Sep 2016 10:26:09 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0D68C6EE11 for ; Thu, 8 Sep 2016 10:26:04 +0000 (UTC) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP; 08 Sep 2016 03:26:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.30,300,1470726000"; d="scan'208"; a="1053038177" Received: from akashgoe-desktop.iind.intel.com ([10.223.82.36]) by fmsmga002.fm.intel.com with ESMTP; 08 Sep 2016 03:26:03 -0700 From: akash.goel@intel.com To: intel-gfx@lists.freedesktop.org Date: Thu, 8 Sep 2016 16:09:18 +0530 Message-Id: <1473331158-21082-19-git-send-email-akash.goel@intel.com> X-Mailer: git-send-email 1.9.2 In-Reply-To: <1473331158-21082-1-git-send-email-akash.goel@intel.com> References: <1473331158-21082-1-git-send-email-akash.goel@intel.com> Cc: Akash Goel Subject: [Intel-gfx] [PATCH 18/18] drm/i915: Mark the GuC log buffer flush interrupts handling WQ as freezable 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-Virus-Scanned: ClamAV using ClamSMTP From: Akash Goel The GuC log buffer flush work item has to do a register access to send the ack to GuC and this work item, if not synced before suspend, can potentially get executed after the GFX device is suspended. This work item function uses rpm get/put calls around the Hw access, which covers the rpm suspend case but for system suspend a sync would be required as kernel can potentially schedule the work items even after some devices, including GFX, have been put to suspend. But sync has to be done only for the system suspend case, as sync along with rpm get/put can cause a deadlock for rpm suspend path. To have the sync, but like a NOOP, for rpm suspend path also this work item could have been queued from the irq handler only when the device is runtime active & kept active while that work item is pending or getting executed but an interrupt can come even after the device is out of use and so can potentially lead to missing of this work item. By marking the workqueue, dedicated for handling GuC log buffer flush interrupts, as freezable we don't have to bother about flushing of this work item from the suspend hooks, the pending work item if any will be either executed before the suspend or scheduled later on resume. This way the handling of log buffer flush work item can be kept same between system suspend & rpm suspend. Suggested-by: Imre Deak Cc: Imre Deak Signed-off-by: Akash Goel Reviewed-by: Imre Deak --- drivers/gpu/drm/i915/i915_guc_submission.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index b9fede0..593a01d 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -1238,8 +1238,19 @@ static int guc_create_log_extras(struct intel_guc *guc) /* Need a dedicated wq to process log buffer flush interrupts * from GuC without much delay so as to avoid any loss of logs. + * + * GuC log buffer flush work item has to do register access to + * send the ack to GuC and this work item, if not synced before + * suspend, can potentially get executed after the GFX device is + * suspended. + * By marking the WQ as freezable, we don't have to bother about + * flushing of this work item from the suspend hooks, the pending + * work item if any will be either executed before the suspend + * or scheduled later on resume. This way the handling of work + * item can be kept same between system suspend & rpm suspend. */ - guc->log.flush_wq = alloc_ordered_workqueue("i915-guc_log", 0); + guc->log.flush_wq = + alloc_ordered_workqueue("i915-guc_log", WQ_FREEZABLE); if (guc->log.flush_wq == NULL) { DRM_ERROR("Couldn't allocate the wq for GuC logging\n"); return -ENOMEM;