drm/i915/uapi: reject set_domain for discrete
[linux-2.6-microblaze.git] / include / uapi / drm / i915_drm.h
index e20eeec..9750875 100644 (file)
@@ -849,31 +849,56 @@ struct drm_i915_gem_mmap_gtt {
        __u64 offset;
 };
 
+/**
+ * struct drm_i915_gem_mmap_offset - Retrieve an offset so we can mmap this buffer object.
+ *
+ * This struct is passed as argument to the `DRM_IOCTL_I915_GEM_MMAP_OFFSET` ioctl,
+ * and is used to retrieve the fake offset to mmap an object specified by &handle.
+ *
+ * The legacy way of using `DRM_IOCTL_I915_GEM_MMAP` is removed on gen12+.
+ * `DRM_IOCTL_I915_GEM_MMAP_GTT` is an older supported alias to this struct, but will behave
+ * as setting the &extensions to 0, and &flags to `I915_MMAP_OFFSET_GTT`.
+ */
 struct drm_i915_gem_mmap_offset {
-       /** Handle for the object being mapped. */
+       /** @handle: Handle for the object being mapped. */
        __u32 handle;
+       /** @pad: Must be zero */
        __u32 pad;
        /**
-        * Fake offset to use for subsequent mmap call
+        * @offset: The fake offset to use for subsequent mmap call
         *
         * This is a fixed-size type for 32/64 compatibility.
         */
        __u64 offset;
 
        /**
-        * Flags for extended behaviour.
+        * @flags: Flags for extended behaviour.
+        *
+        * It is mandatory that one of the `MMAP_OFFSET` types
+        * should be included:
+        *
+        * - `I915_MMAP_OFFSET_GTT`: Use mmap with the object bound to GTT. (Write-Combined)
+        * - `I915_MMAP_OFFSET_WC`: Use Write-Combined caching.
+        * - `I915_MMAP_OFFSET_WB`: Use Write-Back caching.
+        * - `I915_MMAP_OFFSET_FIXED`: Use object placement to determine caching.
         *
-        * It is mandatory that one of the MMAP_OFFSET types
-        * (GTT, WC, WB, UC, etc) should be included.
+        * On devices with local memory `I915_MMAP_OFFSET_FIXED` is the only valid
+        * type. On devices without local memory, this caching mode is invalid.
+        *
+        * As caching mode when specifying `I915_MMAP_OFFSET_FIXED`, WC or WB will
+        * be used, depending on the object placement on creation. WB will be used
+        * when the object can only exist in system memory, WC otherwise.
         */
        __u64 flags;
-#define I915_MMAP_OFFSET_GTT 0
-#define I915_MMAP_OFFSET_WC  1
-#define I915_MMAP_OFFSET_WB  2
-#define I915_MMAP_OFFSET_UC  3
 
-       /*
-        * Zero-terminated chain of extensions.
+#define I915_MMAP_OFFSET_GTT   0
+#define I915_MMAP_OFFSET_WC    1
+#define I915_MMAP_OFFSET_WB    2
+#define I915_MMAP_OFFSET_UC    3
+#define I915_MMAP_OFFSET_FIXED 4
+
+       /**
+        * @extensions: Zero-terminated chain of extensions.
         *
         * No current extensions defined; mbz.
         */
@@ -898,6 +923,25 @@ struct drm_i915_gem_mmap_offset {
  *     - I915_GEM_DOMAIN_GTT: Mappable aperture domain
  *
  * All other domains are rejected.
+ *
+ * Note that for discrete, starting from DG1, this is no longer supported, and
+ * is instead rejected. On such platforms the CPU domain is effectively static,
+ * where we also only support a single &drm_i915_gem_mmap_offset cache mode,
+ * which can't be set explicitly and instead depends on the object placements,
+ * as per the below.
+ *
+ * Implicit caching rules, starting from DG1:
+ *
+ *     - If any of the object placements (see &drm_i915_gem_create_ext_memory_regions)
+ *       contain I915_MEMORY_CLASS_DEVICE then the object will be allocated and
+ *       mapped as write-combined only.
+ *
+ *     - Everything else is always allocated and mapped as write-back, with the
+ *       guarantee that everything is also coherent with the GPU.
+ *
+ * Note that this is likely to change in the future again, where we might need
+ * more flexibility on future devices, so making this all explicit as part of a
+ * new &drm_i915_gem_create_ext extension is probable.
  */
 struct drm_i915_gem_set_domain {
        /** @handle: Handle for the object. */