Commit eeac18e2 authored by Arnaldo Carvalho de Melo's avatar Arnaldo Carvalho de Melo
Browse files

tools headers UAPI: Sync drm/i915_drm.h with the kernel sources 

To pick up the changes in:

  bc7ed4d3 ("drm/i915/perf: Apply Wa_18013179988")
  81d5f7d9 ("drm/i915/perf: Add 32-bit OAG and OAR formats for DG2")
  8133a6da ("drm/i915: enable PS64 support for DG2")
  b76c14c8 ("drm/i915/huc: better define HuC status getparam possible return values.")
  94dfc73e ("treewide: uapi: Replace zero-length arrays with flexible-array members")

That doesn't add any ioctl, so no changes in tooling.

This silences this perf build warning:

  Warning: Kernel ABI header at 'tools/include/uapi/drm/i915_drm.h' differs from latest version at 'include/uapi/drm/i915_drm.h'
  diff -u tools/include/uapi/drm/i915_drm.h include/uapi/drm/i915_drm.h

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://lore.kernel.org/lkml/Y6HukoRaZh2R4j5U@kernel.org


Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
parent 43a3ce77

tools/include/uapi/drm/i915_drm.h

+36 −26
Original line number Diff line number Diff line
@@ -645,6 +645,22 @@ typedef struct drm_i915_irq_wait { 
 */

#define   I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP	(1ul << 5)



/*

 * Query the status of HuC load.

 *

 * The query can fail in the following scenarios with the listed error codes:

 *  -ENODEV if HuC is not present on this platform,

 *  -EOPNOTSUPP if HuC firmware usage is disabled,

 *  -ENOPKG if HuC firmware fetch failed,

 *  -ENOEXEC if HuC firmware is invalid or mismatched,

 *  -ENOMEM if i915 failed to prepare the FW objects for transfer to the uC,

 *  -EIO if the FW transfer or the FW authentication failed.

 *

 * If the IOCTL is successful, the returned parameter will be set to one of the

 * following values:

 *  * 0 if HuC firmware load is not complete,

 *  * 1 if HuC firmware is authenticated and running.

 */

#define I915_PARAM_HUC_STATUS		 42



/* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of
@@ -749,6 +765,12 @@ typedef struct drm_i915_irq_wait { 
/* Query if the kernel supports the I915_USERPTR_PROBE flag. */

#define I915_PARAM_HAS_USERPTR_PROBE 56



/*

 * Frequency of the timestamps in OA reports. This used to be the same as the CS

 * timestamp frequency, but differs on some platforms.

 */

#define I915_PARAM_OA_TIMESTAMP_FREQUENCY 57



/* Must be kept compact -- no holes and well documented */



/**
@@ -2650,6 +2672,10 @@ enum drm_i915_oa_format { 
	I915_OA_FORMAT_A12_B8_C8,

	I915_OA_FORMAT_A32u40_A4u32_B8_C8,



	/* DG2 */

	I915_OAR_FORMAT_A32u40_A4u32_B8_C8,

	I915_OA_FORMAT_A24u40_A14u32_B8_C8,



	I915_OA_FORMAT_MAX	    /* non-ABI */

};
@@ -3493,27 +3519,13 @@ struct drm_i915_gem_create_ext { 
	 *

	 * The (page-aligned) allocated size for the object will be returned.

	 *

	 * DG2 64K min page size implications:

	 *

	 * On discrete platforms, starting from DG2, we have to contend with GTT

	 * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE

	 * objects.  Specifically the hardware only supports 64K or larger GTT

	 * page sizes for such memory. The kernel will already ensure that all

	 * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page

	 * sizes underneath.

	 *

	 * Note that the returned size here will always reflect any required

	 * rounding up done by the kernel, i.e 4K will now become 64K on devices

	 * such as DG2. The kernel will always select the largest minimum

	 * page-size for the set of possible placements as the value to use when

	 * rounding up the @size.

	 *

	 * Special DG2 GTT address alignment requirement:

	 *

	 * The GTT alignment will also need to be at least 2M for such objects.

	 * On platforms like DG2/ATS the kernel will always use 64K or larger

	 * pages for I915_MEMORY_CLASS_DEVICE. The kernel also requires a

	 * minimum of 64K GTT alignment for such objects.

	 *

	 * Note that due to how the hardware implements 64K GTT page support, we

	 * have some further complications:

	 * NOTE: Previously the ABI here required a minimum GTT alignment of 2M

	 * on DG2/ATS, due to how the hardware implemented 64K GTT page support,

	 * where we had the following complications:

	 *

	 *   1) The entire PDE (which covers a 2MB virtual address range), must

	 *   contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
@@ -3522,12 +3534,10 @@ struct drm_i915_gem_create_ext { 
	 *   2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM

	 *   objects.

	 *

	 * To keep things simple for userland, we mandate that any GTT mappings

	 * must be aligned to and rounded up to 2MB. The kernel will internally

	 * pad them out to the next 2MB boundary. As this only wastes virtual

	 * address space and avoids userland having to copy any needlessly

	 * complicated PDE sharing scheme (coloring) and only affects DG2, this

	 * is deemed to be a good compromise.

	 * However on actual production HW this was completely changed to now

	 * allow setting a TLB hint at the PTE level (see PS64), which is a lot

	 * more flexible than the above. With this the 2M restriction was

	 * dropped where we now only require 64K.

	 */

	__u64 size;