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 B6A08C433EF for ; Fri, 17 Jun 2022 04:51:02 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 27FD911AEE4; Fri, 17 Jun 2022 04:50:58 +0000 (UTC) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0149511AEE5; Fri, 17 Jun 2022 04:50:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655441457; x=1686977457; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=LAhnRfWUPa3MF9KyyB3HIOCYp9E4fYVlcR3NiP7pKnc=; b=MbelyG1IDXXJf7P6ZUlqQRLFyGdmU/qzBWmmQb14dR19mXTFULKwojzR xr8RNeuxhOfmeq/BSYedZ9NbPC+1x4LKkJQ7E/SpGvefKIjEmIidT8Jps xL5g6OCYK2lCmlD5EQsJr8jZD2UIGWqdWi6DCnWYKFaHS6X0IsLX7qoJu uxe1Y3DcZguifjmZZUNFbtKV61Ou/6qtyJg8ro1ViSQsd2wVd5+hE6vaY XvRlDoLbpq/JT8WsR+C+MEUZNBCaPHXjYIR+JT2KDqfl/7enAkR4KDRmb W1dBh0j6StK7YSaumakarncMHY96tkzXDOkPW2s7GtmpDJZ3P2Mz0v9Ii A==; X-IronPort-AV: E=McAfee;i="6400,9594,10380"; a="365771473" X-IronPort-AV: E=Sophos;i="5.92,306,1650956400"; d="scan'208";a="365771473" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2022 21:50:56 -0700 X-IronPort-AV: E=Sophos;i="5.92,306,1650956400"; d="scan'208";a="641880939" Received: from adixit-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.141.64]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2022 21:50:56 -0700 Date: Thu, 16 Jun 2022 21:50:55 -0700 Message-ID: <87letvx58w.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Zhanjun Dong In-Reply-To: <20220616220158.15778-1-zhanjun.dong@intel.com> References: <20220616220158.15778-1-zhanjun.dong@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 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).