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 EC9B6ECAAD8 for ; Fri, 16 Sep 2022 05:16:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 955B210E3AF; Fri, 16 Sep 2022 05:16:36 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 697D310E3AF for ; Fri, 16 Sep 2022 05:16:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663305391; x=1694841391; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=lYquJlbhVNzrL7CKaEBQ9uS3X/uhohWwJZTeA8jtlkE=; b=j/G0q2CFfpWPxlwbyXBq0b+qQ2ZxwThdOBl5dzBTk3VLt2wl7ExymiZ1 7pLSjF2eWFblR+kEdD+qlYEp6oE/UbesdmnZgT3UL1mcxsxbHPTl4dIdt 51FhF30c0jnMfF5oXoWA25oaseA2c1ixOyC2pVGSVmngvXYCDicEhJVy7 ZAABjp7ctl+RiD3UNelix81nDCvUdORIcLLw6tsZClzHVeOV4DXDRYVp6 Pqqak/BC6+6duOb8ZEqRGEhIofYE3ncYxXc/oJG0YHZgsMV4ZCoBfyH+L r7O4c5eZzQ81mkq+yPg26+LXuQwHrhYBH790W2c1JsrlPNKkZQGrbf3WR A==; X-IronPort-AV: E=McAfee;i="6500,9779,10471"; a="279295722" X-IronPort-AV: E=Sophos;i="5.93,319,1654585200"; d="scan'208";a="279295722" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2022 22:16:30 -0700 X-IronPort-AV: E=Sophos;i="5.93,319,1654585200"; d="scan'208";a="686005927" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.41.22]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2022 22:16:30 -0700 Date: Thu, 15 Sep 2022 22:16:30 -0700 Message-ID: <875yhn526p.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: <20220823204155.8178-17-umesh.nerlige.ramappa@intel.com> References: <20220823204155.8178-1-umesh.nerlige.ramappa@intel.com> <20220823204155.8178-17-umesh.nerlige.ramappa@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 16/19] drm/i915/perf: Apply Wa_18013179988 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, 23 Aug 2022 13:41:52 -0700, Umesh Nerlige Ramappa wrote: > Hi Umesh, > OA reports in the OA buffer contain an OA timestamp field that helps > user calculate delta between 2 OA reports. The calculation relies on the > CS timestamp frequency to convert the timestamp value to nanoseconds. > The CS timestamp frequency is a function of the CTC_SHIFT value in > RPM_CONFIG0. > > In DG2, OA unit assumes that the CTC_SHIFT is 3, instead of using the > actual value from RPM_CONFIG0. At the user level, this results in an > error in calculating delta between 2 OA reports since the OA timestamp > is not shifted in the same manner as CS timestamp. > > To resolve this, return actual OA timestamp frequency to the user in > i915_getparam_ioctl. Rather than exposing actual OA timestamp frequency to userspace (with the corresponding uapi change, specially if it's only DG2 and not all future products) questions about a couple of other options: Option 1. Can we set CTC_SHIFT in RPM_CONFIG0 to 3, so change GT freq to be the same as OA freq :-) The HSD seems to mention this: Is setting CTC SHIFT to 0b11 on driver init an acceptable W/A? Note: Changing the shift setting on live driver may break apps that are currently running (including desktop manager). Option 2. Is it possible to correct the timestamps in OA report headers to compensate for the difference between OA and GT frequencies (say when copying OA data to userspace)? Though not sure if this is preferable to having userspace do this. A couple of minor optional nits on that patch below too. > +u32 i915_perf_oa_timestamp_frequency(struct drm_i915_private *i915) > +{ > + /* Wa_18013179988:dg2 */ > + if (IS_DG2(i915)) { > + intel_wakeref_t wakeref; > + u32 reg, shift; > + > + with_intel_runtime_pm(to_gt(i915)->uncore->rpm, wakeref) > + reg = intel_uncore_read(to_gt(i915)->uncore, RPM_CONFIG0); > + > + shift = (reg & GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK) >> > + GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT; This can be: shift = REG_FIELD_GET(GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK, reg); > static u64 oa_exponent_to_ns(struct i915_perf *perf, int exponent) > { > - return intel_gt_clock_interval_to_ns(to_gt(perf->i915), > - 2ULL << exponent); > + u64 nom = (2ULL << exponent) * NSEC_PER_SEC; > + u32 den = i915_perf_oa_timestamp_frequency(perf->i915); > + > + return div_u64(nom + den - 1, den); div_u64_roundup? Thanks. -- Ashutosh