From patchwork Fri Apr 8 12:51:59 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislav Lisovskiy X-Patchwork-Id: 12806709 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 02C33C433F5 for ; Fri, 8 Apr 2022 12:51:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9CFD910F163; Fri, 8 Apr 2022 12:51:18 +0000 (UTC) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1BDF210F128 for ; Fri, 8 Apr 2022 12:51:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649422276; x=1680958276; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=xgrvevO6W9+bevhqZ83qCfJFS4mYq9Y4WOvMHyOgr1E=; b=nOhxZijh8DwRoC2PWRCDQSLc8YMkVdX1TRTCxP3Ya+pleTlrs8RdDXoc 4ScN09/RLMVvy4nT0KlEcSRvIj0oU3zyctmsHR6h19VIG1ajQZwsfVz3v pPm9pTmyan1lRUEy7lKydWsBULnu4N0Ub0TsevSwmozjimBvz67pt7ep/ 3vkWFWTwNHc385PxKaGBXOBH4aQi5pr5+1thgpHKTVXm8lsu91pXXHI02 JtEJnktZvdbzWDnLOUfcB/syap1fYXq1LC5xmSHIRd4+XrL97nGo3Xq7g +TQVveqkapVe3K9LApkE2KZ3vHMbkQsBf8m/nBlz7KP+8NO2BJzQHw1V6 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10310"; a="322273321" X-IronPort-AV: E=Sophos;i="5.90,245,1643702400"; d="scan'208";a="322273321" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 05:51:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,245,1643702400"; d="scan'208";a="550491211" Received: from unknown (HELO slisovsk-Lenovo-ideapad-720S-13IKB.fi.intel.com) ([10.237.72.65]) by orsmga007.jf.intel.com with ESMTP; 08 Apr 2022 05:51:14 -0700 From: Stanislav Lisovskiy To: intel-gfx@lists.freedesktop.org Date: Fri, 8 Apr 2022 15:51:59 +0300 Message-Id: <20220408125200.9069-2-stanislav.lisovskiy@intel.com> X-Mailer: git-send-email 2.24.1.485.gad05a3d8e5 In-Reply-To: <20220408125200.9069-1-stanislav.lisovskiy@intel.com> References: <20220408125200.9069-1-stanislav.lisovskiy@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 1/2] drm/i915: Fix skl_pcode_try_request function 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: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Currently skl_pcode_try_request function doesn't properly handle return value it gets from snb_pcode_rw, but treats status != 0 as success, returning true, which basically doesn't allow to use retry/timeout mechanisms if PCode happens to be busy and returns EGAIN or some other status code not equal to 0. We saw this on real hw and also tried simulating this by always returning -EAGAIN from snb_pcode_rw for 6 times, which currently will just result in false success, while it should have tried until timeout is reached: [ 22.357729] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0 [ 22.357831] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1 [ 22.357892] i915 0000:00:02.0: [drm:skl_pcode_request [i915]] Success, exiting [ 22.357936] i915 0000:00:02.0: [drm] ERROR Failed to inform PCU about cdclk change (err -11, freq 307200) We see en error because higher level api, still notices that status was wrong, however we still did try only once. We fix it by requiring _both_ the status to be 0 and request/reply match for success(true) and function should return failure(false) if either status turns out to be EAGAIN, EBUSY or whatever or reply/request masks do not match. So now we see this in the logs: [ 22.318667] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0 [ 22.318782] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1 [ 22.318849] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 2 [ 22.319006] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 3 [ 22.319091] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 4 [ 22.319158] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 5 [ 22.319224] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 6 Reviewed-by: Vinod Govindapillai Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_pcode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pcode.c b/drivers/gpu/drm/i915/intel_pcode.c index 391a37492ce5..fb6c43e8a02f 100644 --- a/drivers/gpu/drm/i915/intel_pcode.c +++ b/drivers/gpu/drm/i915/intel_pcode.c @@ -136,7 +136,7 @@ static bool skl_pcode_try_request(struct drm_i915_private *i915, u32 mbox, { *status = __snb_pcode_rw(i915, mbox, &request, NULL, 500, 0, true); - return *status || ((request & reply_mask) == reply); + return (*status == 0) && ((request & reply_mask) == reply); } /** From patchwork Fri Apr 8 12:52:00 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislav Lisovskiy X-Patchwork-Id: 12806710 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 B384BC433EF for ; Fri, 8 Apr 2022 12:51:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0A6C110F173; Fri, 8 Apr 2022 12:51:19 +0000 (UTC) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7F78410F15D for ; Fri, 8 Apr 2022 12:51:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649422278; x=1680958278; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vAH6wF+7f1W8aggyMHeNcKMFmoF7grHJvegIGSHa+Zk=; b=hho33BF3l31lgF19Tt9bX7wcWZuVq5TnBE2VvSskFsyjVirn+BVedvXK t+vmPw/56pNdRlNS6YxjpGO8v45Wsj0Z5bApJ1oH74QqTRA+POoLaGyZ1 e0CJOz906I5D3ivUj86naSlrtukiDO+5wLurru+xA+tVW4lBIfZwZ+r/a joHqA/xrhuTGxkqzdFyKzSS4kqFPG2mSLaU9B6OPR/a4a0x8/v635lgBN iU9x4CqPN5RHS4PBh0MSmg0JcrnycHD1aU6Zb1Zq1t1uEz99K4YnsSIhc 8LRgUKeZ/tcBObyYGf9hkd7l6fhi0KSEu5Gi444lMdSD1GM7oqqZS7cnr g==; X-IronPort-AV: E=McAfee;i="6400,9594,10310"; a="322273330" X-IronPort-AV: E=Sophos;i="5.90,245,1643702400"; d="scan'208";a="322273330" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 05:51:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,245,1643702400"; d="scan'208";a="550491222" Received: from unknown (HELO slisovsk-Lenovo-ideapad-720S-13IKB.fi.intel.com) ([10.237.72.65]) by orsmga007.jf.intel.com with ESMTP; 08 Apr 2022 05:51:16 -0700 From: Stanislav Lisovskiy To: intel-gfx@lists.freedesktop.org Date: Fri, 8 Apr 2022 15:52:00 +0300 Message-Id: <20220408125200.9069-3-stanislav.lisovskiy@intel.com> X-Mailer: git-send-email 2.24.1.485.gad05a3d8e5 In-Reply-To: <20220408125200.9069-1-stanislav.lisovskiy@intel.com> References: <20220408125200.9069-1-stanislav.lisovskiy@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 2/2] drm/i915: Swap ret and status returned from skl_pcode_request 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: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" If ret isn't zero, it is almost for sure ETIMEDOUT, because we use it in wait_for macro which does continuous retries until timeout is reached. If we still ran out of time and retries, we most likely would be interested in getting status, to understand what was the actual error propagated from PCode, rather than to find out that we had a time out, which is anyway quite obvious, if the function fails. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_pcode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pcode.c b/drivers/gpu/drm/i915/intel_pcode.c index fb6c43e8a02f..a68eaf510784 100644 --- a/drivers/gpu/drm/i915/intel_pcode.c +++ b/drivers/gpu/drm/i915/intel_pcode.c @@ -202,7 +202,7 @@ int skl_pcode_request(struct drm_i915_private *i915, u32 mbox, u32 request, out: mutex_unlock(&i915->sb_lock); - return ret ? ret : status; + return ret ? status : ret; #undef COND }