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 5C979C38145 for ; Wed, 7 Sep 2022 07:31:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 45D1C10E3D9; Wed, 7 Sep 2022 07:31:14 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id BAE0510E3BE for ; Wed, 7 Sep 2022 07:31:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662535869; x=1694071869; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=W02Yiqo2YlpnpOFnE2xwKREacLxKbKvHJwbUO6KSGUc=; b=JFZAQsGigps3ioI0kV397tOPRJjZ4pU+tQ4mmrLqCcUS72Hz2nEcUwTR /pezIP0LGfvjMjGdAanEBHRYQWUVdLL7DgLQHv1YAB/PMQdA0KCvNQIQa lTSuzQmAK/qXZUf38UwzTdmdnra7Kyc4ZNCdAHIQcu5/fhDvdYVO6DbKo dYD0JGO5CC4jRT9KdMYRBfA9ICQDsK6VicX+nk/3wRFwc9Q3GrM8vkWgv ypOmvyj/WkWEmK71LE9KzmJ5ceoNWccW/ristdlQ1SkmvO1ZdMLWrDRB5 3f5O4Bvn5//Ibqn46xiSE2H2GIlZRf7CTiPLx+btNOxjYOigbRsaRPkRJ g==; X-IronPort-AV: E=McAfee;i="6500,9779,10462"; a="277196853" X-IronPort-AV: E=Sophos;i="5.93,296,1654585200"; d="scan'208";a="277196853" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2022 00:31:09 -0700 X-IronPort-AV: E=Sophos;i="5.93,296,1654585200"; d="scan'208";a="789959087" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.84.184]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2022 00:31:08 -0700 Date: Wed, 07 Sep 2022 00:31:08 -0700 Message-ID: <875yhzy72b.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Rodrigo Vivi In-Reply-To: References: <20220902235302.1112388-1-ashutosh.dixit@intel.com> <20220902235302.1112388-5-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 4/6] drm/i915/debugfs: Add perf_limit_reasons in debugfs 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 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 06 Sep 2022 07:13:03 -0700, Rodrigo Vivi wrote: > Copying author. > On Fri, Sep 02, 2022 at 04:53:00PM -0700, Ashutosh Dixit wrote: > > From: Tilak Tangudu > > > > Add perf_limit_reasons in debugfs. Unlike the lower 16 perf_limit_reasons > > status bits, the upper 16 log bits remain set until cleared, thereby > > ensuring the throttling occurrence is not missed. The clear fop clears > > the upper 16 log bits, the get fop gets all 32 log and status bits. > > > > Signed-off-by: Tilak Tangudu > > --- > > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 27 +++++++++++++++++++ > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > 2 files changed, 28 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > > index 108b9e76c32e..5c95cba5e5df 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > > @@ -655,6 +655,32 @@ static bool rps_eval(void *data) > > > > DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost); > > > > +static int perf_limit_reasons_get(void *data, u64 *val) > > +{ > > + struct intel_gt *gt = data; > > + intel_wakeref_t wakeref; > > + > > + with_intel_runtime_pm(gt->uncore->rpm, wakeref) > > + *val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS); > > + > > + return 0; > > +} > > + > > +static int perf_limit_reasons_clear(void *data, u64 val) > > +{ > > + struct intel_gt *gt = data; > > + intel_wakeref_t wakeref; > > + > > + /* Clear the upper 16 log bits, the lower 16 status bits are read-only */ > > + with_intel_runtime_pm(gt->uncore->rpm, wakeref) > > + intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS, > > + GT0_PERF_LIMIT_REASONS_LOG_MASK, 0); > > + > > + return 0; > > +} > > +DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get, > > + perf_limit_reasons_clear, "%llu\n"); > > + > > void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root) > > { > > static const struct intel_gt_debugfs_file files[] = { > > @@ -664,6 +690,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root) > > { "forcewake_user", &forcewake_user_fops, NULL}, > > { "llc", &llc_fops, llc_eval }, > > { "rps_boost", &rps_boost_fops, rps_eval }, > > + { "perf_limit_reasons", &perf_limit_reasons_fops, NULL }, > > }; > > > > intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt); > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > > index 5e6239864c35..10126995e1f6 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -1802,6 +1802,7 @@ > > #define POWER_LIMIT_4_MASK REG_BIT(9) > > #define POWER_LIMIT_1_MASK REG_BIT(11) > > #define POWER_LIMIT_2_MASK REG_BIT(12) > > +#define GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16) > > Is this valid for all platforms? > What does the bits are really telling us? > Could we expand the reasons? The previous bits we know exactly > what kind of limits we are dealing of, but with this combined > one without any explanation I'm afraid this will bring more > confusion than help. We will get bugged by many folks trying > to debug this out there when bit 13, for instance, is set. > "What does bit 13 mean?" will be a recurrent question with > only a tribal knowledge kind of answer. > > > > > #define CHV_CLK_CTL1 _MMIO(0x101100) > > #define VLV_CLK_CTL2 _MMIO(0x101104) > > -- > > 2.34.1 > >