From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: <igt-dev@lists.freedesktop.org>
Subject: Re: [PATCH i-g-t 1/4] drm-uapi/xe: Sync with DRM_XE_OA_CAPS_OA_UNIT_GT_ID definition
Date: Thu, 04 Dec 2025 18:44:23 -0800 [thread overview]
Message-ID: <87pl8tprzs.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <aTIxXnBjmxGzvj0d@soc-5CG1426VCC.clients.intel.com>
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 <ashutosh.dixit@intel.com>
>
> 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.
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
> >
next prev parent reply other threads:[~2025-12-05 2:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-05 0:05 [PATCH v2 i-g-t 0/4] OA: Run MMIO trigger tests on all OA units Ashutosh Dixit
2025-12-05 0:05 ` [PATCH i-g-t 1/4] drm-uapi/xe: Sync with DRM_XE_OA_CAPS_OA_UNIT_GT_ID definition Ashutosh Dixit
2025-12-05 1:11 ` Umesh Nerlige Ramappa
2025-12-05 2:44 ` Dixit, Ashutosh [this message]
2025-12-05 20:21 ` Umesh Nerlige Ramappa
2025-12-05 20:28 ` Dixit, Ashutosh
2025-12-05 20:40 ` Umesh Nerlige Ramappa
2025-12-05 0:05 ` [PATCH i-g-t 2/4] tests/intel/xe_oa: Return hwe from same gt from oa_unit_engine() Ashutosh Dixit
2025-12-05 1:08 ` Umesh Nerlige Ramappa
2025-12-05 0:05 ` [PATCH i-g-t 3/4] tests/intel/xe_oa: Run mmio-trigger tests on all OA units Ashutosh Dixit
2025-12-05 0:05 ` [PATCH i-g-t 4/4] tests/intel/xe_oa: Use separate oa unit variables for caps and iterator Ashutosh Dixit
2025-12-05 19:58 ` ✗ i915.CI.BAT: failure for OA: Run MMIO trigger tests on all OA units (rev2) Patchwork
2025-12-05 20:15 ` ✓ Xe.CI.BAT: success " Patchwork
2025-12-06 3:29 ` ✗ Xe.CI.Full: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pl8tprzs.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=umesh.nerlige.ramappa@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.