Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Francois Dugast <francois.dugast@intel.com>
Cc: <igt-dev@lists.freedesktop.org>,
	Kamil Konieczny <kamil.konieczny@linux.intel.com>,
	 Mauro Carvalho Chehab <mauro.chehab@linux.intel.com>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	 Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Matt Roper <matthew.d.roper@intel.com>
Subject: Re: [PATCH i-g-t] drm-uapi: Align header with drm-xe-next
Date: Thu, 28 Mar 2024 14:17:04 -0700	[thread overview]
Message-ID: <857chmvyy7.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20240328173243.7-1-francois.dugast@intel.com>

On Thu, 28 Mar 2024 10:32:43 -0700, Francois Dugast wrote:
>

Hi Francois,

> Currently xe_drm.h is based on drm-next with some additions from
> drm-xe-next.
>
> However some uAPI updates brought by commit ca4607939 ("drm-uapi/xe: \
> Remove unused flags") were mistakenly reverted by commit aef5f4742
> ("drm-uapi: sync with drm-next f112b68f273f").
>
> Ensure xe_drm.h is now aligned with kernel commit ("drm/xe/uapi: Add \
> IP version and stepping to GT list query").

Let me copy some people and see what they say and what we should be doing
here.

Previously we were making sure that IGT uapi files in include/drm-uapi/
were in sync with kernel drm-next branch. I am not sure what the reason for
doing this was. When we were doing this, any definitions not in drm-next
were put in lib/i915/i915_drm_local.h.

So should we be doing this now even for Xe or not? Or we can just keep the
IGT uapi headers in sync with drm-xe-next (or drm-tip)? If not, we would
need to create a lib/xe/xe_drm_local.h and put stuff not in drm-next there.

This patch syncs IGT with the uapi header in drm-xe-next. If this is ok,
this is:

Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>



>
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Signed-off-by: Francois Dugast <francois.dugast@intel.com>
> ---
>  include/drm-uapi/xe_drm.h | 19 -------------------
>  1 file changed, 19 deletions(-)
>
> diff --git a/include/drm-uapi/xe_drm.h b/include/drm-uapi/xe_drm.h
> index 4353595a4..91ea92035 100644
> --- a/include/drm-uapi/xe_drm.h
> +++ b/include/drm-uapi/xe_drm.h
> @@ -871,10 +871,6 @@ struct drm_xe_vm_destroy {
>   *  - %DRM_XE_VM_BIND_OP_PREFETCH
>   *
>   * and the @flags can be:
> - *  - %DRM_XE_VM_BIND_FLAG_READONLY
> - *  - %DRM_XE_VM_BIND_FLAG_IMMEDIATE - Valid on a faulting VM only, do the
> - *    MAP operation immediately rather than deferring the MAP to the page
> - *    fault handler.
>   *  - %DRM_XE_VM_BIND_FLAG_NULL - When the NULL flag is set, the page
>   *    tables are setup with a special bit which indicates writes are
>   *    dropped and all reads return zero. In the future, the NULL flags
> @@ -967,8 +963,6 @@ struct drm_xe_vm_bind_op {
>	/** @op: Bind operation to perform */
>	__u32 op;
>
> -#define DRM_XE_VM_BIND_FLAG_READONLY	(1 << 0)
> -#define DRM_XE_VM_BIND_FLAG_IMMEDIATE	(1 << 1)
>  #define DRM_XE_VM_BIND_FLAG_NULL	(1 << 2)
>  #define DRM_XE_VM_BIND_FLAG_DUMPABLE	(1 << 3)
>	/** @flags: Bind flags */
> @@ -1085,19 +1079,6 @@ struct drm_xe_exec_queue_create {
>  #define DRM_XE_EXEC_QUEUE_EXTENSION_SET_PROPERTY		0
>  #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_PREEMPTION_TIMEOUT	2
> -#define   DRM_XE_EXEC_QUEUE_SET_PROPERTY_JOB_TIMEOUT		4
> -#define   DRM_XE_EXEC_QUEUE_SET_PROPERTY_ACC_TRIGGER		5
> -#define   DRM_XE_EXEC_QUEUE_SET_PROPERTY_ACC_NOTIFY		6
> -#define   DRM_XE_EXEC_QUEUE_SET_PROPERTY_ACC_GRANULARITY	7
> -/* Monitor 128KB contiguous region with 4K sub-granularity */
> -#define     DRM_XE_ACC_GRANULARITY_128K				0
> -/* Monitor 2MB contiguous region with 64KB sub-granularity */
> -#define     DRM_XE_ACC_GRANULARITY_2M				1
> -/* Monitor 16MB contiguous region with 512KB sub-granularity */
> -#define     DRM_XE_ACC_GRANULARITY_16M				2
> -/* Monitor 64MB contiguous region with 2M sub-granularity */
> -#define     DRM_XE_ACC_GRANULARITY_64M				3
>
>	/** @extensions: Pointer to the first extension struct, if any */
>	__u64 extensions;
> --
> 2.34.1
>

  reply	other threads:[~2024-03-28 21:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 17:32 [PATCH i-g-t] drm-uapi: Align header with drm-xe-next Francois Dugast
2024-03-28 21:17 ` Dixit, Ashutosh [this message]
2024-03-28 23:51   ` Lucas De Marchi
2024-03-28 23:26 ` ✓ Fi.CI.BAT: success for " Patchwork
2024-03-28 23:35 ` ✓ CI.xeBAT: " Patchwork
2024-03-29 17:52 ` ✗ Fi.CI.IGT: 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=857chmvyy7.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=francois.dugast@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=kamil.konieczny@linux.intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=mauro.chehab@linux.intel.com \
    --cc=rodrigo.vivi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox