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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id C768CC433EF for ; Tue, 12 Jul 2022 19:47:39 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0B56C963A6; Tue, 12 Jul 2022 19:47:39 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 51CAC96045; Tue, 12 Jul 2022 19:47:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657655258; x=1689191258; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=64I2oEgDCZCUu4WSmvnw+cvK6cQZkiC3lIQ35FQq1iI=; b=aOW5TDef0if2c0WvaMhzG3p52mXi9glQD6LPgSbU91lph07KdR+G7luq /5s8qBlkmp0LzYhxvd4MYjxCmM6P26QeEkvDH+VICACqGa12aW2tWw8q2 4zV0nRQGzsoqymQCLDfipchVuFKFwCfm2KgljJxrQtoNTmojqjPtwZqQA uSPwb3LpCkm95teG5B50FeXqeybT2+004PdfY5Z6xtyVeXJ/4OB7uJoT8 VinwHoty2U2vdyHyL1RcaxHWPBI5BgrRPyoa0lpAbKoRkiqPhpXQj8DLK jcZrcAgTXmpsCrA9XYzp/5kSvZBhyEwHYurQ5zSZJd083l3mbs+zVpW/M A==; X-IronPort-AV: E=McAfee;i="6400,9594,10406"; a="264817639" X-IronPort-AV: E=Sophos;i="5.92,266,1650956400"; d="scan'208";a="264817639" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2022 12:47:37 -0700 X-IronPort-AV: E=Sophos;i="5.92,266,1650956400"; d="scan'208";a="545553646" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.39.190]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2022 12:47:37 -0700 Date: Tue, 12 Jul 2022 12:47:36 -0700 Message-ID: <87pmiam7tz.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Zhanjun Dong In-Reply-To: <87letvx58w.wl-ashutosh.dixit@intel.com> References: <20220616220158.15778-1-zhanjun.dong@intel.com> <87letvx58w.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Check for ct enabled while waiting for response 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: , Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, 16 Jun 2022 21:50:55 -0700, Dixit, Ashutosh wrote: > > On Thu, 16 Jun 2022 15:01:59 -0700, Zhanjun Dong wrote: > > > > We are seeing error message of "No response for request". Some cases > > happened while waiting for response and reset/suspend action was triggered. > > In this case, no response is not an error, active requests will be > > cancelled. > > > > This patch will handle this condition and change the error message into > > debug message. > > > > Signed-off-by: Zhanjun Dong > > --- > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 ++++++++++++++++------- > > 1 file changed, 17 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > index f01325cd1b62..f07a7666b1ad 100644 > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > @@ -455,6 +455,7 @@ static int ct_write(struct intel_guc_ct *ct, > > > > /** > > * wait_for_ct_request_update - Wait for CT request state update. > > + * @ct: pointer to CT > > * @req: pointer to pending request > > * @status: placeholder for status > > * > > @@ -467,9 +468,10 @@ static int ct_write(struct intel_guc_ct *ct, > > * * 0 response received (status is valid) > > * * -ETIMEDOUT no response within hardcoded timeout > > */ > > -static int wait_for_ct_request_update(struct ct_request *req, u32 *status) > > +static int wait_for_ct_request_update(struct intel_guc_ct *ct, struct ct_request *req, u32 *status) > > { > > int err; > > + bool ct_enabled; > > > > /* > > * Fast commands should complete in less than 10us, so sample quickly > > @@ -481,12 +483,15 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status) > > #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10 > > #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000 > > #define done \ > > - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \ > > + (!(ct_enabled = intel_guc_ct_enabled(ct)) || \ > > + FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \ > > GUC_HXG_ORIGIN_GUC) > > err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS); > > if (err) > > err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS); > > #undef done > > + if (!ct_enabled) > > + err = -ECANCELED; > > Actually here's an even simpler suggestion. We could just do: > > if (!ct_enabled) > CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB is disabled\n", ...); > > And return 0 as before. This way we won't have to make any changes in > either ct_send() or intel_guc_ct_send(). So intel_guc_ct_enabled() just > serves to get us out of the wait early and prevent the -ETIMEDOUT return > (and 0 return avoids all the error messages we are trying to eliminate). Actually will need to unlink the request too, so it will be something like: if (!ct_enabled) { CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB is disabled\n", ...); spin_lock_irqsave(&ct->requests.lock, flags); list_del(&request.link); spin_unlock_irqrestore(&ct->requests.lock, flags); }