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 27FA6D37497 for ; Fri, 5 Dec 2025 20:28:58 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CDC0810EBAD; Fri, 5 Dec 2025 20:28:57 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="I/MGkXfI"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8FFC610EBAD for ; Fri, 5 Dec 2025 20:28:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1764966537; x=1796502537; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=VOefe+MzCXgwTLCZso4fOX7jVU8elzhIxrtcQULgbyE=; b=I/MGkXfIzOXLXKZLBnRCZ86o+bUtOGFPGaOWgHr8Q7fFyS4y9W/7gcgi cbBqndPwEwRbt3+eWj3FjAKWQwL6FP/lpT32aUjO4ocaW0xfQmANoid36 8mecOlXByi6M8CTLpCN5RZs6T5T32XEwTTWFygLjCtNfaVJKaSJLxD+98 QleGdLsUxnbSwAVDdDuGq27uo39zlK1EC8P3YXk4FVaXrtvs8MXcPC9CT kobZkod+NxHZMJrk5YLp8YAyhVuLWcEGpkHXFwPFSu5Uv8tiKm/0rLkYE d+HaTAQf4djk8p9F7wVj8Wd+HzbEbOetWK+xwXjIAWRCiFsBk3UE1nl2M A==; X-CSE-ConnectionGUID: TBajZNdFSLS/g6l9JbfcdA== X-CSE-MsgGUID: dHxK9PKzTdyd1zWX7iOKBQ== X-IronPort-AV: E=McAfee;i="6800,10657,11633"; a="66966852" X-IronPort-AV: E=Sophos;i="6.20,252,1758610800"; d="scan'208";a="66966852" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2025 12:28:57 -0800 X-CSE-ConnectionGUID: qzyEYwFuTIaw0GvVL++CIw== X-CSE-MsgGUID: Xm/9EwNeR1mV7CgUMizang== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,252,1758610800"; d="scan'208";a="194682592" Received: from pgopalap-mobl2.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.124.162.149]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2025 12:28:55 -0800 Date: Fri, 05 Dec 2025 12:28:54 -0800 Message-ID: <87o6ocpta1.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Cc: Subject: Re: [PATCH i-g-t 1/4] drm-uapi/xe: Sync with DRM_XE_OA_CAPS_OA_UNIT_GT_ID definition In-Reply-To: References: <20251205000528.720706-1-ashutosh.dixit@intel.com> <20251205000528.720706-2-ashutosh.dixit@intel.com> <87pl8tprzs.wl-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/30.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 X-BeenThere: igt-dev@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development mailing list for IGT GPU Tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" On Fri, 05 Dec 2025 12:21:48 -0800, Umesh Nerlige Ramappa wrote: > > On Thu, Dec 04, 2025 at 06:44:23PM -0800, Dixit, Ashutosh wrote: > > On Thu, 04 Dec 2025 17:11:58 -0800, Umesh Nerlige Ramappa wrote: > >> > > > > Hi Umesh, > > > >> On Thu, Dec 04, 2025 at 04:05:25PM -0800, Ashutosh Dixit wrote: > >> > Align with kernel commit 16e076b03658 ("drm/xe/oa/uapi: Add gt_id to struct > >> > drm_xe_oa_unit") to bring in DRM_XE_OA_CAPS_OA_UNIT_GT_ID definition. > >> > > >> > Signed-off-by: Ashutosh Dixit > >> > >> Is the intention also to bring non-OA changes in this commit? > > > > It's just a sync with kernel xe_drm.h at the commit (latest one) mentioned > > above. So yes it will pull in all the changes till that commit. > > > >> Then you may want to change the commit message to sync header file or > >> something. > > > > It already says sync. Otherwise I just titled the commit as the last change > > that went into the header file. I think anything is ok, but if you or > > anyone else has any suggestions, I will change the title to that one. > > > > Also, if anyone else merges their changes to the header file first (I have > > seen several pending merges on the mail list), this commit will change. But > > it will always be a sync with the kernel header at the mentioned commit. > > I'd recommend - "Sync with kernel header". Hmm, it already says "drm-uapi/xe". See other commit titles for the file. So we need some more indication on what we are adding in the commit title. > > With that, > > Reviewed-by: Umesh Nerlige Ramappa > > Thanks, > Umesh > > > > Thanks. > > -- > > Ashutosh > > > > > >> > --- > >> > include/drm-uapi/xe_drm.h | 55 ++++++++++++++++++++++++++++++++++++--- > >> > 1 file changed, 51 insertions(+), 4 deletions(-) > >> > > >> > diff --git a/include/drm-uapi/xe_drm.h b/include/drm-uapi/xe_drm.h > >> > index 89ab549354..62e3221f59 100644 > >> > --- a/include/drm-uapi/xe_drm.h > >> > +++ b/include/drm-uapi/xe_drm.h > >> > @@ -210,8 +210,12 @@ struct drm_xe_ext_set_property { > >> > /** @pad: MBZ */ > >> > __u32 pad; > >> > > >> > - /** @value: property value */ > >> > - __u64 value; > >> > + union { > >> > + /** @value: property value */ > >> > + __u64 value; > >> > + /** @ptr: pointer to user value */ > >> > + __u64 ptr; > >> > + }; > >> > > >> > /** @reserved: Reserved */ > >> > __u64 reserved[2]; > >> > @@ -403,6 +407,9 @@ struct drm_xe_query_mem_regions { > >> > * has low latency hint support > >> > * - %DRM_XE_QUERY_CONFIG_FLAG_HAS_CPU_ADDR_MIRROR - Flag is set if the > >> > * device has CPU address mirroring support > >> > + * - %DRM_XE_QUERY_CONFIG_FLAG_HAS_NO_COMPRESSION_HINT - Flag is set if the > >> > + * device supports the userspace hint %DRM_XE_GEM_CREATE_FLAG_NO_COMPRESSION. > >> > + * This is exposed only on Xe2+. > >> > * - %DRM_XE_QUERY_CONFIG_MIN_ALIGNMENT - Minimal memory alignment > >> > * required by this device, typically SZ_4K or SZ_64K > >> > * - %DRM_XE_QUERY_CONFIG_VA_BITS - Maximum bits of a virtual address > >> > @@ -421,6 +428,7 @@ struct drm_xe_query_config { > >> > #define DRM_XE_QUERY_CONFIG_FLAG_HAS_VRAM (1 << 0) > >> > #define DRM_XE_QUERY_CONFIG_FLAG_HAS_LOW_LATENCY (1 << 1) > >> > #define DRM_XE_QUERY_CONFIG_FLAG_HAS_CPU_ADDR_MIRROR (1 << 2) > >> > + #define DRM_XE_QUERY_CONFIG_FLAG_HAS_NO_COMPRESSION_HINT (1 << 3) > >> > #define DRM_XE_QUERY_CONFIG_MIN_ALIGNMENT 2 > >> > #define DRM_XE_QUERY_CONFIG_VA_BITS 3 > >> > #define DRM_XE_QUERY_CONFIG_MAX_EXEC_QUEUE_PRIORITY 4 > >> > @@ -771,7 +779,11 @@ struct drm_xe_device_query { > >> > * until the object is either bound to a virtual memory region via > >> > * VM_BIND or accessed by the CPU. As a result, no backing memory is > >> > * reserved at the time of GEM object creation. > >> > - * - %DRM_XE_GEM_CREATE_FLAG_SCANOUT > >> > + * - %DRM_XE_GEM_CREATE_FLAG_SCANOUT - Indicates that the GEM object is > >> > + * intended for scanout via the display engine. When set, kernel ensures > >> > + * that the allocation is placed in a memory region compatible with the > >> > + * display engine requirements. This may impose restrictions on tiling, > >> > + * alignment, and memory placement to guarantee proper display functionality. > >> > * - %DRM_XE_GEM_CREATE_FLAG_NEEDS_VISIBLE_VRAM - When using VRAM as a > >> > * possible placement, ensure that the corresponding VRAM allocation > >> > * will always use the CPU accessible part of VRAM. This is important > >> > @@ -787,6 +799,17 @@ struct drm_xe_device_query { > >> > * need to use VRAM for display surfaces, therefore the kernel requires > >> > * setting this flag for such objects, otherwise an error is thrown on > >> > * small-bar systems. > >> > + * - %DRM_XE_GEM_CREATE_FLAG_NO_COMPRESSION - Allows userspace to > >> > + * hint that compression (CCS) should be disabled for the buffer being > >> > + * created. This can avoid unnecessary memory operations and CCS state > >> > + * management. > >> > + * On pre-Xe2 platforms, this flag is currently rejected as compression > >> > + * control is not supported via PAT index. On Xe2+ platforms, compression > >> > + * is controlled via PAT entries. If this flag is set, the driver will reject > >> > + * any VM bind that requests a PAT index enabling compression for this BO. > >> > + * Note: On dGPU platforms, there is currently no change in behavior with > >> > + * this flag, but future improvements may leverage it. The current benefit is > >> > + * primarily applicable to iGPU platforms. > >> > * > >> > * @cpu_caching supports the following values: > >> > * - %DRM_XE_GEM_CPU_CACHING_WB - Allocate the pages with write-back > >> > @@ -833,6 +856,7 @@ struct drm_xe_gem_create { > >> > #define DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING (1 << 0) > >> > #define DRM_XE_GEM_CREATE_FLAG_SCANOUT (1 << 1) > >> > #define DRM_XE_GEM_CREATE_FLAG_NEEDS_VISIBLE_VRAM (1 << 2) > >> > +#define DRM_XE_GEM_CREATE_FLAG_NO_COMPRESSION (1 << 3) > >> > /** > >> > * @flags: Flags, currently a mask of memory instances of where BO can > >> > * be placed > >> > @@ -1013,6 +1037,20 @@ struct drm_xe_vm_destroy { > >> > * valid on VMs with DRM_XE_VM_CREATE_FLAG_FAULT_MODE set. The CPU address > >> > * mirror flag are only valid for DRM_XE_VM_BIND_OP_MAP operations, the BO > >> > * handle MBZ, and the BO offset MBZ. > >> > + * - %DRM_XE_VM_BIND_FLAG_MADVISE_AUTORESET - Can be used in combination with > >> > + * %DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR to reset madvises when the underlying > >> > + * CPU address space range is unmapped (typically with munmap(2) or brk(2)). > >> > + * The madvise values set with &DRM_IOCTL_XE_MADVISE are reset to the values > >> > + * that were present immediately after the &DRM_IOCTL_XE_VM_BIND. > >> > + * The reset GPU virtual address range is the intersection of the range bound > >> > + * using &DRM_IOCTL_XE_VM_BIND and the virtual CPU address space range > >> > + * unmapped. > >> > + * This functionality is present to mimic the behaviour of CPU address space > >> > + * madvises set using madvise(2), which are typically reset on unmap. > >> > + * Note: free(3) may or may not call munmap(2) and/or brk(2), and may thus > >> > + * not invoke autoreset. Neither will stack variables going out of scope. > >> > + * Therefore it's recommended to always explicitly reset the madvises when > >> > + * freeing the memory backing a region used in a &DRM_IOCTL_XE_MADVISE call. > >> > * > >> > * The @prefetch_mem_region_instance for %DRM_XE_VM_BIND_OP_PREFETCH can also be: > >> > * - %DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC, which ensures prefetching occurs in > >> > @@ -1119,6 +1157,7 @@ struct drm_xe_vm_bind_op { > >> > #define DRM_XE_VM_BIND_FLAG_DUMPABLE (1 << 3) > >> > #define DRM_XE_VM_BIND_FLAG_CHECK_PXP (1 << 4) > >> > #define DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR (1 << 5) > >> > +#define DRM_XE_VM_BIND_FLAG_MADVISE_AUTORESET (1 << 6) > >> > /** @flags: Bind flags */ > >> > __u32 flags; > >> > > >> > @@ -1273,6 +1312,7 @@ struct drm_xe_exec_queue_create { > >> > #define DRM_XE_EXEC_QUEUE_SET_PROPERTY_PRIORITY 0 > >> > #define DRM_XE_EXEC_QUEUE_SET_PROPERTY_TIMESLICE 1 > >> > #define DRM_XE_EXEC_QUEUE_SET_PROPERTY_PXP_TYPE 2 > >> > +#define DRM_XE_EXEC_QUEUE_SET_HANG_REPLAY_STATE 3 > >> > /** @extensions: Pointer to the first extension struct, if any */ > >> > __u64 extensions; > >> > > >> > @@ -1657,12 +1697,19 @@ struct drm_xe_oa_unit { > >> > #define DRM_XE_OA_CAPS_OA_BUFFER_SIZE (1 << 2) > >> > #define DRM_XE_OA_CAPS_WAIT_NUM_REPORTS (1 << 3) > >> > #define DRM_XE_OA_CAPS_OAM (1 << 4) > >> > +#define DRM_XE_OA_CAPS_OA_UNIT_GT_ID (1 << 5) > >> > > >> > /** @oa_timestamp_freq: OA timestamp freq */ > >> > __u64 oa_timestamp_freq; > >> > > >> > + /** @gt_id: gt id for this OA unit */ > >> > + __u16 gt_id; > >> > + > >> > + /** @reserved1: MBZ */ > >> > + __u16 reserved1[3]; > >> > + > >> > /** @reserved: MBZ */ > >> > - __u64 reserved[4]; > >> > + __u64 reserved[3]; > >> > > >> > /** @num_engines: number of engines in @eci array */ > >> > __u64 num_engines; > >> > -- > >> > 2.48.1 > >> >