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 E29E6C77B73 for ; Mon, 22 May 2023 21:50:54 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4387010E2B1; Mon, 22 May 2023 21:50:54 +0000 (UTC) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8859E10E2AB; Mon, 22 May 2023 21:50:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684792252; x=1716328252; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=G6FlKrLrqBhH/jLPVmh+PZ8poJjABSSQ6cowEWQM87E=; b=YCmOG4AY6GQs3gj0iUCJi0p/R8Gp+vECWOoZkBN55sPbQdLt73xvzlFu jO+5Z/DCU5YBsiYYqc4y8iBZ0hZdSPCPlK95cUfvYTk9GsoPNTt1wSc4R dTdB3uCUaka5hLX2d7Lq2hPMbjKZXjDTMLiESGcYpe+dj75dltz8IkeJ8 rEjHceVDElcV9SRCtPZBbbu8Ui86jmU2LrebzjSQ2F0YwjJhqnD7lHCzl vp4Wf7fqysg1U4nF4pEIKfTBQciCYIvfm7/aXwxQbdyWd5efYLtO1f6O2 fMI/XGecBkpLXNsuGGebxIK8QAkwPs9fB1VvpCNdXHXePJ4sw5K/lBHDZ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10718"; a="353076272" X-IronPort-AV: E=Sophos;i="6.00,184,1681196400"; d="scan'208";a="353076272" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2023 14:50:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10718"; a="827845789" X-IronPort-AV: E=Sophos;i="6.00,184,1681196400"; d="scan'208";a="827845789" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.251.0.15]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2023 14:50:51 -0700 Date: Mon, 22 May 2023 14:50:51 -0700 Message-ID: <87lehgqblw.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: References: <20230522201749.4094742-1-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] drm/i915/perf: Clear out entire reports after reading if not power of 2 size 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 Mon, 22 May 2023 14:34:18 -0700, Umesh Nerlige Ramappa wrote: > > On Mon, May 22, 2023 at 01:17:49PM -0700, Ashutosh Dixit wrote: > > Clearing out report id and timestamp as means to detect unlanded reports > > only works if report size is power of 2. That is, only when report size is > > a sub-multiple of the OA buffer size can we be certain that reports will > > land at the same place each time in the OA buffer (after rewind). If report > > size is not a power of 2, we need to zero out the entire report to be able > > to detect unlanded reports reliably. > > > > Cc: Umesh Nerlige Ramappa > > Signed-off-by: Ashutosh Dixit > > --- > > drivers/gpu/drm/i915/i915_perf.c | 17 +++++++++++------ > > 1 file changed, 11 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c > > index 19d5652300eeb..58284156428dc 100644 > > --- a/drivers/gpu/drm/i915/i915_perf.c > > +++ b/drivers/gpu/drm/i915/i915_perf.c > > @@ -877,12 +877,17 @@ static int gen8_append_oa_reports(struct i915_perf_stream *stream, > > stream->oa_buffer.last_ctx_id = ctx_id; > > } > > > > - /* > > - * Clear out the report id and timestamp as a means to detect unlanded > > - * reports. > > - */ > > - oa_report_id_clear(stream, report32); > > - oa_timestamp_clear(stream, report32); > > + if (is_power_of_2(report_size)) { > > + /* > > + * Clear out the report id and timestamp as a means > > + * to detect unlanded reports. > > + */ > > + oa_report_id_clear(stream, report32); > > + oa_timestamp_clear(stream, report32); > > + } else { > > + /* Zero out the entire report */ > > + memset(report32, 0, report_size); > > Indeed, this was a bug. For a minute, I started wondering if this is the > issue I am running into with the other patch posted for DG2, but then I see > the issue within the first fill of the OA buffer where chunks of the > reports are zeroed out, so this is a new issue. Yes I saw this while reviewing your patch. And also I thought your issue was happening on DG2 with power of 2 report size, only on MTL OAM we introduce non power of 2 report size. > lgtm, > > Reviewed-by: Umesh Nerlige Ramappa Thanks. -- Ashutosh > > > + } > > } > > > > if (start_offset != *offset) { > > -- > > 2.38.0 > >