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 971A4C61DA4 for ; Wed, 15 Mar 2023 23:54:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AD52510E35F; Wed, 15 Mar 2023 23:54:31 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id 72FB310E35F; Wed, 15 Mar 2023 23:54:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678924470; x=1710460470; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=g+3w27bzPiYzUzZORXJe/7R7CDbxyIwgk8PRaJ7TfJg=; b=RM6pA1XmFOSSaXRDEWpgKso1KSLyvbIcsP2LW6zzw4wcNucuQhAavObW 9B8jyL2Xcv2vU2pJWFkMT4pn/3IsvE3+P/LQmf9iG0poA2e2QIDWqELGW Pyqz0pWAN9EQNiNcD7f1U1MiIHPK/ZndZ3CkTnW1iAyHUY7Or14jfpEuE 3n5vvv4cHXsJvbcxjugDGypM2U72+TCbIoKPGh20/NXojjh8YRUWwuv4v 8r8W24wwtXSrlPxj994wrUn7a+jLPG2r6MHzPcnUFAsTKKXYDpdMGhf3C QphMLUQn0beeHB+m1aWZfNixd32cRXGnwgRAN4YXON4voaxGSUPhzcpWa g==; X-IronPort-AV: E=McAfee;i="6500,9779,10650"; a="402715993" X-IronPort-AV: E=Sophos;i="5.98,262,1673942400"; d="scan'208";a="402715993" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2023 16:54:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10650"; a="629640442" X-IronPort-AV: E=Sophos;i="5.98,262,1673942400"; d="scan'208";a="629640442" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.13.197]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2023 16:54:28 -0700 Date: Wed, 15 Mar 2023 16:54:28 -0700 Message-ID: <87r0tpwoy3.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Tvrtko Ursulin In-Reply-To: References: <20230310005943.1029333-1-ashutosh.dixit@intel.com> <20230310005943.1029333-3-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.2 (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 2/2] drm/i915/pmu: Remove fallback to requested freq for SLPC 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, Rodrigo Vivi Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, 15 Mar 2023 02:50:17 -0700, Tvrtko Ursulin wrote: > > On 10/03/2023 00:59, Ashutosh Dixit wrote: > > The fallback to requested freq does not work for SLPC because SLPC does not > > use 'struct intel_rps'. Also for SLPC requested freq can only be obtained > > from a hw register after acquiring forcewake which we don't want to do for > > PMU. Therefore remove fallback to requested freq for SLPC. The actual freq > > will be 0 when gt is in RC6 which is correct. Also this is rare since PMU > > freq sampling happens only when gt is unparked. > > > > Signed-off-by: Ashutosh Dixit > > --- > > drivers/gpu/drm/i915/i915_pmu.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c > > index 7ece883a7d95..f697fabed64a 100644 > > --- a/drivers/gpu/drm/i915/i915_pmu.c > > +++ b/drivers/gpu/drm/i915/i915_pmu.c > > @@ -393,7 +393,14 @@ frequency_sample(struct intel_gt *gt, unsigned int period_ns) > > * frequency. Fortunately, the read should rarely fail! > > */ > > val = intel_rps_read_actual_frequency_fw(rps); > > - if (!val) > > + > > + /* > > + * SLPC does not use 'struct intel_rps'. Also for SLPC > > + * requested freq can only be obtained after acquiring > > + * forcewake and reading a hw register. For SLPC just > > + * let val be 0 > > + */ > > + if (!val && !intel_uc_uses_guc_slpc(>->uc)) > > val = intel_gpu_freq(rps, rps->cur_freq); > > I really dislike sprinkling of "uses slpc" since I think the thing hasn't > really been integrated nicely. Case in point is probably the flow duality > in intel_rps_boost. Data structures as well, even though some fields and > concepts are shared. > > For instance why we can't have the notion of software tracked cur_freq in > rps, and/or have it zero if with SLPC we can't have it otherwise? For SLPC: * We can't have the notion of software tracked cur_freq in rps because FW is managing the freq. * rps->cur_freq /is/ actually 0 since SLPC does not use 'struct intel_rps'. So this patch doesn't really make any practical difference, PMU values will be exactly the same with or without this patch. It was just clarifying things. > I will abstain, sorry. I will drop this patch, there doesn't seem much point in it. Thanks. -- Ashutosh