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 9A76BC4167D for ; Sat, 4 Nov 2023 01:23:10 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3CFA710E1B0; Sat, 4 Nov 2023 01:23:10 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0885B10E1B0 for ; Sat, 4 Nov 2023 01:23:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699060988; x=1730596988; h=date:message-id:from:to:subject:in-reply-to:references: mime-version; bh=Gezc8W2W+QSHAsVui0wbOEOb3M2S4pyT6O7Y/KvEvdQ=; b=bxmUHNybp+jlVmYZO4dzlFOCPFF3yEqLMzn1MoiHC/HLezd8xT62tVHF RAlo4M4jaJ1BBNi7DNizBjqUQw/ilNxTCdRXNZn/cKgo8gAyGBz+9Jz07 Rj4E7rwNpt+9VVqx5sV315H5YfvRwBmorhL5cXRRiNrrTUZNd9Ex/Hu2m OHcFIkBBNF3yZh2YHzDUgAJMWVeTNgvLyOEABtoBOwDs5N0X60ZRtNAAx qRESpCQh77CSYDpNLv4H/QPO4Y6mwaG5HSTJUKZEKQXUjX9BVhXB6hbc8 fKWCEovR0KBIzjduRzPgIMLBamwwZxLnUbEhmoe/1nRkt7RBQX+4MUTRH A==; X-IronPort-AV: E=McAfee;i="6600,9927,10883"; a="1931664" X-IronPort-AV: E=Sophos;i="6.03,275,1694761200"; d="scan'208";a="1931664" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2023 18:23:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.03,275,1694761200"; d="scan'208";a="2910650" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.252.136.205]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2023 18:23:08 -0700 Date: Fri, 03 Nov 2023 18:23:07 -0700 Message-ID: <87wmuyfh1g.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: intel-xe@lists.freedesktop.org, Umesh Nerlige Ramappa In-Reply-To: <20230919161049.2307855-2-ashutosh.dixit@intel.com> References: <20230919161049.2307855-1-ashutosh.dixit@intel.com> <20230919161049.2307855-2-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/29.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-xe] [PATCH 01/21] drm/xe/uapi: Introduce OA (observability architecture) uapi X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Tue, 19 Sep 2023 09:10:29 -0700, Ashutosh Dixit wrote: > Hi Umesh, > +struct drm_xe_oa_record_header { > + __u32 type; > + __u16 pad; > + __u16 size; > +}; > + > +enum drm_xe_oa_record_type { > + /** > + * Samples are the work horse record type whose contents are > + * extensible and defined when opening an xe oa stream based on the > + * given properties. > + * > + * Boolean properties following the naming convention > + * DRM_XE_OA_SAMPLE_xyz_PROP request the inclusion of 'xyz' data in > + * every sample. > + * > + * The order of these sample properties given by userspace has no > + * affect on the ordering of data within a sample. The order is > + * documented here. > + * > + * struct { > + * struct drm_xe_oa_record_header header; > + * > + * { u32 oa_report[]; } && DRM_XE_OA_PROP_SAMPLE_OA > + * }; > + */ > + DRM_XE_OA_RECORD_SAMPLE = 1, > + > + /** > + * Indicates that one or more OA reports were not written by the > + * hardware. This can happen for example if an MI_REPORT_PERF_COUNT > + * command collides with periodic sampling - which would be more likely > + * at higher sampling frequencies. > + */ > + DRM_XE_OA_RECORD_OA_REPORT_LOST = 2, > + > + /** > + * An error occurred that resulted in all pending OA reports being lost. > + */ > + DRM_XE_OA_RECORD_OA_BUFFER_LOST = 3, > + > + DRM_XE_OA_RECORD_MAX /* non-ABI */ Rather than maintain these statuses in the uapi, how about just returning oa_status register (from which these statuses come) directly to userland. Basically the 32 bit type can directly be the oa_status register directly. We can steal bit 31 (or something like that) to indicate a real SAMPLE vs a status header. This way only bit 31 gets into xe_drm.h. Thoughts? Thanks. -- Ashutosh