[PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915.

[PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915.

[Maarten Lankhorst]

I believe small_bar has been implemented, as is gem_lmem.

xe has implemented GuC submission and VM_BIND, but realistically
this will never happen for i915.

Either way, those RFC's are completed, and can be removed.

Maarten Lankhorst (4):
  drm/doc/rfc: Remove i915_gem_lmem.rst
  drm/doc/rfc: Remove i915_vm_bind.
  drm/doc/rfc: Remove i915_small_bar rfc.
  drm/doc/rfc: Remove i915_scheduler item.

 Documentation/gpu/rfc/i915_gem_lmem.rst  |  22 --
 Documentation/gpu/rfc/i915_scheduler.rst | 152 ------------
 Documentation/gpu/rfc/i915_small_bar.h   | 189 ---------------
 Documentation/gpu/rfc/i915_small_bar.rst |  47 ----
 Documentation/gpu/rfc/i915_vm_bind.h     | 290 -----------------------
 Documentation/gpu/rfc/i915_vm_bind.rst   | 245 -------------------
 Documentation/gpu/rfc/index.rst          |  18 +-
 7 files changed, 1 insertion(+), 962 deletions(-)
 delete mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
 delete mode 100644 Documentation/gpu/rfc/i915_scheduler.rst
 delete mode 100644 Documentation/gpu/rfc/i915_small_bar.h
 delete mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
 delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
 delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst

-- 
2.53.0

[PATCH 1/4] drm/doc/rfc: Remove i915_gem_lmem.rst

[Maarten Lankhorst]

The doc talks about DG1, but we do already support DG2 in i915, and
a new driver was created specifically to handle all lmem cases
even better.

Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
 Documentation/gpu/rfc/i915_gem_lmem.rst | 22 ----------------------
 Documentation/gpu/rfc/index.rst         |  6 +-----
 2 files changed, 1 insertion(+), 27 deletions(-)
 delete mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst

diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst
deleted file mode 100644
index b421a3c1806ec..0000000000000
--- a/Documentation/gpu/rfc/i915_gem_lmem.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-=========================
-I915 DG1/LMEM RFC Section
-=========================
-
-Upstream plan
-=============
-For upstream the overall plan for landing all the DG1 stuff and turning it for
-real, with all the uAPI bits is:
-
-* Merge basic HW enabling of DG1(still without pciid)
-* Merge the uAPI bits behind special CONFIG_BROKEN(or so) flag
-        * At this point we can still make changes, but importantly this lets us
-          start running IGTs which can utilize local-memory in CI
-* Convert over to TTM, make sure it all keeps working. Some of the work items:
-        * TTM shrinker for discrete
-        * dma_resv_lockitem for full dma_resv_lock, i.e not just trylock
-        * Use TTM CPU pagefault handler
-        * Route shmem backend over to TTM SYSTEM for discrete
-        * TTM purgeable object support
-        * Move i915 buddy allocator over to TTM
-* Send RFC(with mesa-dev on cc) for final sign off on the uAPI
-* Add pciid for DG1 and turn on uAPI for real
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index ef19b0ba2a3ea..8313194af0683 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -20,10 +20,6 @@ host such documentation:
 
     gpusvm.rst
 
-.. toctree::
-
-    i915_gem_lmem.rst
-
 .. toctree::
 
     i915_scheduler.rst
@@ -37,4 +33,4 @@ host such documentation:
     i915_vm_bind.rst
 
 .. toctree::
-    color_pipeline.rst
\ No newline at end of file
+    color_pipeline.rst
-- 
2.53.0

[PATCH 2/4] drm/doc/rfc: Remove i915_vm_bind.

[Maarten Lankhorst]

i915 supports soft pinning, and the xe driver
has been created to properly support VM_BIND instead.

Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
 Documentation/gpu/rfc/i915_vm_bind.h   | 290 -------------------------
 Documentation/gpu/rfc/i915_vm_bind.rst | 245 ---------------------
 Documentation/gpu/rfc/index.rst        |   4 -
 3 files changed, 539 deletions(-)
 delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
 delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h b/Documentation/gpu/rfc/i915_vm_bind.h
deleted file mode 100644
index bc26dc1261041..0000000000000
--- a/Documentation/gpu/rfc/i915_vm_bind.h
+++ /dev/null
@@ -1,290 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-/*
- * Copyright © 2022 Intel Corporation
- */
-
-/**
- * DOC: I915_PARAM_VM_BIND_VERSION
- *
- * VM_BIND feature version supported.
- * See typedef drm_i915_getparam_t param.
- *
- * Specifies the VM_BIND feature version supported.
- * The following versions of VM_BIND have been defined:
- *
- * 0: No VM_BIND support.
- *
- * 1: In VM_UNBIND calls, the UMD must specify the exact mappings created
- *    previously with VM_BIND, the ioctl will not support unbinding multiple
- *    mappings or splitting them. Similarly, VM_BIND calls will not replace
- *    any existing mappings.
- *
- * 2: The restrictions on unbinding partial or multiple mappings is
- *    lifted, Similarly, binding will replace any mappings in the given range.
- *
- * See struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind.
- */
-#define I915_PARAM_VM_BIND_VERSION	57
-
-/**
- * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
- *
- * Flag to opt-in for VM_BIND mode of binding during VM creation.
- * See struct drm_i915_gem_vm_control flags.
- *
- * The older execbuf2 ioctl will not support VM_BIND mode of operation.
- * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
- * execlist (See struct drm_i915_gem_execbuffer3 for more details).
- */
-#define I915_VM_CREATE_FLAGS_USE_VM_BIND	(1 << 0)
-
-/* VM_BIND related ioctls */
-#define DRM_I915_GEM_VM_BIND		0x3d
-#define DRM_I915_GEM_VM_UNBIND		0x3e
-#define DRM_I915_GEM_EXECBUFFER3	0x3f
-
-#define DRM_IOCTL_I915_GEM_VM_BIND		DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
-#define DRM_IOCTL_I915_GEM_VM_UNBIND		DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
-#define DRM_IOCTL_I915_GEM_EXECBUFFER3		DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
-
-/**
- * struct drm_i915_gem_timeline_fence - An input or output timeline fence.
- *
- * The operation will wait for input fence to signal.
- *
- * The returned output fence will be signaled after the completion of the
- * operation.
- */
-struct drm_i915_gem_timeline_fence {
-	/** @handle: User's handle for a drm_syncobj to wait on or signal. */
-	__u32 handle;
-
-	/**
-	 * @flags: Supported flags are:
-	 *
-	 * I915_TIMELINE_FENCE_WAIT:
-	 * Wait for the input fence before the operation.
-	 *
-	 * I915_TIMELINE_FENCE_SIGNAL:
-	 * Return operation completion fence as output.
-	 */
-	__u32 flags;
-#define I915_TIMELINE_FENCE_WAIT            (1 << 0)
-#define I915_TIMELINE_FENCE_SIGNAL          (1 << 1)
-#define __I915_TIMELINE_FENCE_UNKNOWN_FLAGS (-(I915_TIMELINE_FENCE_SIGNAL << 1))
-
-	/**
-	 * @value: A point in the timeline.
-	 * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
-	 * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
-	 * binary one.
-	 */
-	__u64 value;
-};
-
-/**
- * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
- *
- * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
- * virtual address (VA) range to the section of an object that should be bound
- * in the device page table of the specified address space (VM).
- * The VA range specified must be unique (ie., not currently bound) and can
- * be mapped to whole object or a section of the object (partial binding).
- * Multiple VA mappings can be created to the same section of the object
- * (aliasing).
- *
- * The @start, @offset and @length must be 4K page aligned. However the DG2 has
- * 64K page size for device local memory and has compact page table. On that
- * platform, for binding device local-memory objects, the @start, @offset and
- * @length must be 64K aligned. Also, UMDs should not mix the local memory 64K
- * page and the system memory 4K page bindings in the same 2M range.
- *
- * Error code -EINVAL will be returned if @start, @offset and @length are not
- * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error code
- * -ENOSPC will be returned if the VA range specified can't be reserved.
- *
- * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
- * are not ordered. Furthermore, parts of the VM_BIND operation can be done
- * asynchronously, if valid @fence is specified.
- */
-struct drm_i915_gem_vm_bind {
-	/** @vm_id: VM (address space) id to bind */
-	__u32 vm_id;
-
-	/** @handle: Object handle */
-	__u32 handle;
-
-	/** @start: Virtual Address start to bind */
-	__u64 start;
-
-	/** @offset: Offset in object to bind */
-	__u64 offset;
-
-	/** @length: Length of mapping to bind */
-	__u64 length;
-
-	/**
-	 * @flags: Supported flags are:
-	 *
-	 * I915_GEM_VM_BIND_CAPTURE:
-	 * Capture this mapping in the dump upon GPU error.
-	 *
-	 * Note that @fence carries its own flags.
-	 */
-	__u64 flags;
-#define I915_GEM_VM_BIND_CAPTURE	(1 << 0)
-
-	/**
-	 * @fence: Timeline fence for bind completion signaling.
-	 *
-	 * Timeline fence is of format struct drm_i915_gem_timeline_fence.
-	 *
-	 * It is an out fence, hence using I915_TIMELINE_FENCE_WAIT flag
-	 * is invalid, and an error will be returned.
-	 *
-	 * If I915_TIMELINE_FENCE_SIGNAL flag is not set, then out fence
-	 * is not requested and binding is completed synchronously.
-	 */
-	struct drm_i915_gem_timeline_fence fence;
-
-	/**
-	 * @extensions: Zero-terminated chain of extensions.
-	 *
-	 * For future extensions. See struct i915_user_extension.
-	 */
-	__u64 extensions;
-};
-
-/**
- * struct drm_i915_gem_vm_unbind - VA to object mapping to unbind.
- *
- * This structure is passed to VM_UNBIND ioctl and specifies the GPU virtual
- * address (VA) range that should be unbound from the device page table of the
- * specified address space (VM). VM_UNBIND will force unbind the specified
- * range from device page table without waiting for any GPU job to complete.
- * It is UMDs responsibility to ensure the mapping is no longer in use before
- * calling VM_UNBIND.
- *
- * If the specified mapping is not found, the ioctl will simply return without
- * any error.
- *
- * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
- * are not ordered. Furthermore, parts of the VM_UNBIND operation can be done
- * asynchronously, if valid @fence is specified.
- */
-struct drm_i915_gem_vm_unbind {
-	/** @vm_id: VM (address space) id to bind */
-	__u32 vm_id;
-
-	/** @rsvd: Reserved, MBZ */
-	__u32 rsvd;
-
-	/** @start: Virtual Address start to unbind */
-	__u64 start;
-
-	/** @length: Length of mapping to unbind */
-	__u64 length;
-
-	/**
-	 * @flags: Currently reserved, MBZ.
-	 *
-	 * Note that @fence carries its own flags.
-	 */
-	__u64 flags;
-
-	/**
-	 * @fence: Timeline fence for unbind completion signaling.
-	 *
-	 * Timeline fence is of format struct drm_i915_gem_timeline_fence.
-	 *
-	 * It is an out fence, hence using I915_TIMELINE_FENCE_WAIT flag
-	 * is invalid, and an error will be returned.
-	 *
-	 * If I915_TIMELINE_FENCE_SIGNAL flag is not set, then out fence
-	 * is not requested and unbinding is completed synchronously.
-	 */
-	struct drm_i915_gem_timeline_fence fence;
-
-	/**
-	 * @extensions: Zero-terminated chain of extensions.
-	 *
-	 * For future extensions. See struct i915_user_extension.
-	 */
-	__u64 extensions;
-};
-
-/**
- * struct drm_i915_gem_execbuffer3 - Structure for DRM_I915_GEM_EXECBUFFER3
- * ioctl.
- *
- * DRM_I915_GEM_EXECBUFFER3 ioctl only works in VM_BIND mode and VM_BIND mode
- * only works with this ioctl for submission.
- * See I915_VM_CREATE_FLAGS_USE_VM_BIND.
- */
-struct drm_i915_gem_execbuffer3 {
-	/**
-	 * @ctx_id: Context id
-	 *
-	 * Only contexts with user engine map are allowed.
-	 */
-	__u32 ctx_id;
-
-	/**
-	 * @engine_idx: Engine index
-	 *
-	 * An index in the user engine map of the context specified by @ctx_id.
-	 */
-	__u32 engine_idx;
-
-	/**
-	 * @batch_address: Batch gpu virtual address/es.
-	 *
-	 * For normal submission, it is the gpu virtual address of the batch
-	 * buffer. For parallel submission, it is a pointer to an array of
-	 * batch buffer gpu virtual addresses with array size equal to the
-	 * number of (parallel) engines involved in that submission (See
-	 * struct i915_context_engines_parallel_submit).
-	 */
-	__u64 batch_address;
-
-	/** @flags: Currently reserved, MBZ */
-	__u64 flags;
-
-	/** @rsvd1: Reserved, MBZ */
-	__u32 rsvd1;
-
-	/** @fence_count: Number of fences in @timeline_fences array. */
-	__u32 fence_count;
-
-	/**
-	 * @timeline_fences: Pointer to an array of timeline fences.
-	 *
-	 * Timeline fences are of format struct drm_i915_gem_timeline_fence.
-	 */
-	__u64 timeline_fences;
-
-	/** @rsvd2: Reserved, MBZ */
-	__u64 rsvd2;
-
-	/**
-	 * @extensions: Zero-terminated chain of extensions.
-	 *
-	 * For future extensions. See struct i915_user_extension.
-	 */
-	__u64 extensions;
-};
-
-/**
- * struct drm_i915_gem_create_ext_vm_private - Extension to make the object
- * private to the specified VM.
- *
- * See struct drm_i915_gem_create_ext.
- */
-struct drm_i915_gem_create_ext_vm_private {
-#define I915_GEM_CREATE_EXT_VM_PRIVATE		2
-	/** @base: Extension link. See struct i915_user_extension. */
-	struct i915_user_extension base;
-
-	/** @vm_id: Id of the VM to which the object is private */
-	__u32 vm_id;
-};
diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst
deleted file mode 100644
index 0b3b525ac6200..0000000000000
--- a/Documentation/gpu/rfc/i915_vm_bind.rst
+++ /dev/null
@@ -1,245 +0,0 @@
-==========================================
-I915 VM_BIND feature design and use cases
-==========================================
-
-VM_BIND feature
-================
-DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
-objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
-specified address space (VM). These mappings (also referred to as persistent
-mappings) will be persistent across multiple GPU submissions (execbuf calls)
-issued by the UMD, without user having to provide a list of all required
-mappings during each submission (as required by older execbuf mode).
-
-The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
-signaling the completion of bind/unbind operation.
-
-VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION.
-User has to opt-in for VM_BIND mode of binding for an address space (VM)
-during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
-
-VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently are
-not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be done
-asynchronously, when valid out fence is specified.
-
-VM_BIND features include:
-
-* Multiple Virtual Address (VA) mappings can map to the same physical pages
-  of an object (aliasing).
-* VA mapping can map to a partial section of the BO (partial binding).
-* Support capture of persistent mappings in the dump upon GPU error.
-* Support for userptr gem objects (no special uapi is required for this).
-
-TLB flush consideration
-------------------------
-The i915 driver flushes the TLB for each submission and when an object's
-pages are released. The VM_BIND/UNBIND operation will not do any additional
-TLB flush. Any VM_BIND mapping added will be in the working set for subsequent
-submissions on that VM and will not be in the working set for currently running
-batches (which would require additional TLB flushes, which is not supported).
-
-Execbuf ioctl in VM_BIND mode
--------------------------------
-A VM in VM_BIND mode will not support older execbuf mode of binding.
-The execbuf ioctl handling in VM_BIND mode differs significantly from the
-older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
-Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
-struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
-execlist. Hence, no support for implicit sync. It is expected that the below
-work will be able to support requirements of object dependency setting in all
-use cases:
-
-"dma-buf: Add an API for exporting sync files"
-(https://lwn.net/Articles/859290/)
-
-The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
-works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
-VM_BIND call) at the time of execbuf3 call are deemed required for that
-submission.
-
-The execbuf3 ioctl directly specifies the batch addresses instead of as
-object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
-support many of the older features like in/out/submit fences, fence array,
-default gem context and many more (See struct drm_i915_gem_execbuffer3).
-
-In VM_BIND mode, VA allocation is completely managed by the user instead of
-the i915 driver. Hence all VA assignment, eviction are not applicable in
-VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
-be using the i915_vma active reference tracking. It will instead use dma-resv
-object for that (See `VM_BIND dma_resv usage`_).
-
-So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA
-evictions, vma lookup table, implicit sync, vma active reference tracking etc.,
-are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling
-should be in a separate file and only functionalities common to these ioctls
-can be the shared code where possible.
-
-VM_PRIVATE objects
--------------------
-By default, BOs can be mapped on multiple VMs and can also be dma-buf
-exported. Hence these BOs are referred to as Shared BOs.
-During each execbuf submission, the request fence must be added to the
-dma-resv fence list of all shared BOs mapped on the VM.
-
-VM_BIND feature introduces an optimization where user can create BO which
-is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during
-BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on
-the VM they are private to and can't be dma-buf exported.
-All private BOs of a VM share the dma-resv object. Hence during each execbuf
-submission, they need only one dma-resv fence list updated. Thus, the fast
-path (where required mappings are already bound) submission latency is O(1)
-w.r.t the number of VM private BOs.
-
-VM_BIND locking hierarchy
--------------------------
-The locking design here supports the older (execlist based) execbuf mode, the
-newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future
-system allocator support (See `Shared Virtual Memory (SVM) support`_).
-The older execbuf mode and the newer VM_BIND mode without page faults manages
-residency of backing storage using dma_fence. The VM_BIND mode with page faults
-and the system allocator support do not use any dma_fence at all.
-
-VM_BIND locking order is as below.
-
-1) Lock-A: A vm_bind mutex will protect vm_bind lists. This lock is taken in
-   vm_bind/vm_unbind ioctl calls, in the execbuf path and while releasing the
-   mapping.
-
-   In future, when GPU page faults are supported, we can potentially use a
-   rwsem instead, so that multiple page fault handlers can take the read side
-   lock to lookup the mapping and hence can run in parallel.
-   The older execbuf mode of binding do not need this lock.
-
-2) Lock-B: The object's dma-resv lock will protect i915_vma state and needs to
-   be held while binding/unbinding a vma in the async worker and while updating
-   dma-resv fence list of an object. Note that private BOs of a VM will all
-   share a dma-resv object.
-
-   The future system allocator support will use the HMM prescribed locking
-   instead.
-
-3) Lock-C: Spinlock/s to protect some of the VM's lists like the list of
-   invalidated vmas (due to eviction and userptr invalidation) etc.
-
-When GPU page faults are supported, the execbuf path do not take any of these
-locks. There we will simply smash the new batch buffer address into the ring and
-then tell the scheduler run that. The lock taking only happens from the page
-fault handler, where we take lock-A in read mode, whichever lock-B we need to
-find the backing storage (dma_resv lock for gem objects, and hmm/core mm for
-system allocator) and some additional locks (lock-D) for taking care of page
-table races. Page fault mode should not need to ever manipulate the vm lists,
-so won't ever need lock-C.
-
-VM_BIND LRU handling
----------------------
-We need to ensure VM_BIND mapped objects are properly LRU tagged to avoid
-performance degradation. We will also need support for bulk LRU movement of
-VM_BIND objects to avoid additional latencies in execbuf path.
-
-The page table pages are similar to VM_BIND mapped objects (See
-`Evictable page table allocations`_) and are maintained per VM and needs to
-be pinned in memory when VM is made active (ie., upon an execbuf call with
-that VM). So, bulk LRU movement of page table pages is also needed.
-
-VM_BIND dma_resv usage
------------------------
-Fences needs to be added to all VM_BIND mapped objects. During each execbuf
-submission, they are added with DMA_RESV_USAGE_BOOKKEEP usage to prevent
-over sync (See enum dma_resv_usage). One can override it with either
-DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE usage during explicit object
-dependency setting.
-
-Note that DRM_I915_GEM_WAIT and DRM_I915_GEM_BUSY ioctls do not check for
-DMA_RESV_USAGE_BOOKKEEP usage and hence should not be used for end of batch
-check. Instead, the execbuf3 out fence should be used for end of batch check
-(See struct drm_i915_gem_execbuffer3).
-
-Also, in VM_BIND mode, use dma-resv apis for determining object activeness
-(See dma_resv_test_signaled() and dma_resv_wait_timeout()) and do not use the
-older i915_vma active reference tracking which is deprecated. This should be
-easier to get it working with the current TTM backend.
-
-Mesa use case
---------------
-VM_BIND can potentially reduce the CPU overhead in Mesa (both Vulkan and Iris),
-hence improving performance of CPU-bound applications. It also allows us to
-implement Vulkan's Sparse Resources. With increasing GPU hardware performance,
-reducing CPU overhead becomes more impactful.
-
-
-Other VM_BIND use cases
-========================
-
-Long running Compute contexts
-------------------------------
-Usage of dma-fence expects that they complete in reasonable amount of time.
-Compute on the other hand can be long running. Hence it is appropriate for
-compute to use user/memory fence (See `User/Memory Fence`_) and dma-fence usage
-must be limited to in-kernel consumption only.
-
-Where GPU page faults are not available, kernel driver upon buffer invalidation
-will initiate a suspend (preemption) of long running context, finish the
-invalidation, revalidate the BO and then resume the compute context. This is
-done by having a per-context preempt fence which is enabled when someone tries
-to wait on it and triggers the context preemption.
-
-User/Memory Fence
-~~~~~~~~~~~~~~~~~~
-User/Memory fence is a <address, value> pair. To signal the user fence, the
-specified value will be written at the specified virtual address and wakeup the
-waiting process. User fence can be signaled either by the GPU or kernel async
-worker (like upon bind completion). User can wait on a user fence with a new
-user fence wait ioctl.
-
-Here is some prior work on this:
-https://patchwork.freedesktop.org/patch/349417/
-
-Low Latency Submission
-~~~~~~~~~~~~~~~~~~~~~~~
-Allows compute UMD to directly submit GPU jobs instead of through execbuf
-ioctl. This is made possible by VM_BIND is not being synchronized against
-execbuf. VM_BIND allows bind/unbind of mappings required for the directly
-submitted jobs.
-
-Debugger
----------
-With debug event interface user space process (debugger) is able to keep track
-of and act upon resources created by another process (debugged) and attached
-to GPU via vm_bind interface.
-
-GPU page faults
-----------------
-GPU page faults when supported (in future), will only be supported in the
-VM_BIND mode. While both the older execbuf mode and the newer VM_BIND mode of
-binding will require using dma-fence to ensure residency, the GPU page faults
-mode when supported, will not use any dma-fence as residency is purely managed
-by installing and removing/invalidating page table entries.
-
-Page level hints settings
---------------------------
-VM_BIND allows any hints setting per mapping instead of per BO. Possible hints
-include placement and atomicity. Sub-BO level placement hint will be even more
-relevant with upcoming GPU on-demand page fault support.
-
-Page level Cache/CLOS settings
--------------------------------
-VM_BIND allows cache/CLOS settings per mapping instead of per BO.
-
-Evictable page table allocations
----------------------------------
-Make pagetable allocations evictable and manage them similar to VM_BIND
-mapped objects. Page table pages are similar to persistent mappings of a
-VM (difference here are that the page table pages will not have an i915_vma
-structure and after swapping pages back in, parent page link needs to be
-updated).
-
-Shared Virtual Memory (SVM) support
-------------------------------------
-VM_BIND interface can be used to map system memory directly (without gem BO
-abstraction) using the HMM interface. SVM is only supported with GPU page
-faults enabled.
-
-VM_BIND UAPI
-=============
-
-.. kernel-doc:: Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 8313194af0683..1256dde0fb3b1 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -28,9 +28,5 @@ host such documentation:
 
     i915_small_bar.rst
 
-.. toctree::
-
-    i915_vm_bind.rst
-
 .. toctree::
     color_pipeline.rst
-- 
2.53.0

[PATCH 3/4] drm/doc/rfc: Remove i915_small_bar rfc.

[Maarten Lankhorst]

Probably done, with commit 525e93f6317a ("drm/i915/uapi: add NEEDS_CPU_ACCESS hint")
and 3f4309cbdc84 ("drm/i915/uapi: add probed_cpu_visible_size")

Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
 Documentation/gpu/rfc/i915_small_bar.h   | 189 -----------------------
 Documentation/gpu/rfc/i915_small_bar.rst |  47 ------
 Documentation/gpu/rfc/index.rst          |   4 -
 3 files changed, 240 deletions(-)
 delete mode 100644 Documentation/gpu/rfc/i915_small_bar.h
 delete mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h b/Documentation/gpu/rfc/i915_small_bar.h
deleted file mode 100644
index 6003c81d5aa40..0000000000000
--- a/Documentation/gpu/rfc/i915_small_bar.h
+++ /dev/null
@@ -1,189 +0,0 @@
-/**
- * struct __drm_i915_memory_region_info - Describes one region as known to the
- * driver.
- *
- * Note this is using both struct drm_i915_query_item and struct drm_i915_query.
- * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS
- * at &drm_i915_query_item.query_id.
- */
-struct __drm_i915_memory_region_info {
-	/** @region: The class:instance pair encoding */
-	struct drm_i915_gem_memory_class_instance region;
-
-	/** @rsvd0: MBZ */
-	__u32 rsvd0;
-
-	/**
-	 * @probed_size: Memory probed by the driver
-	 *
-	 * Note that it should not be possible to ever encounter a zero value
-	 * here, also note that no current region type will ever return -1 here.
-	 * Although for future region types, this might be a possibility. The
-	 * same applies to the other size fields.
-	 */
-	__u64 probed_size;
-
-	/**
-	 * @unallocated_size: Estimate of memory remaining
-	 *
-	 * Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable accounting.
-	 * Without this (or if this is an older kernel) the value here will
-	 * always equal the @probed_size. Note this is only currently tracked
-	 * for I915_MEMORY_CLASS_DEVICE regions (for other types the value here
-	 * will always equal the @probed_size).
-	 */
-	__u64 unallocated_size;
-
-	union {
-		/** @rsvd1: MBZ */
-		__u64 rsvd1[8];
-		struct {
-			/**
-			 * @probed_cpu_visible_size: Memory probed by the driver
-			 * that is CPU accessible.
-			 *
-			 * This will be always be <= @probed_size, and the
-			 * remainder (if there is any) will not be CPU
-			 * accessible.
-			 *
-			 * On systems without small BAR, the @probed_size will
-			 * always equal the @probed_cpu_visible_size, since all
-			 * of it will be CPU accessible.
-			 *
-			 * Note this is only tracked for
-			 * I915_MEMORY_CLASS_DEVICE regions (for other types the
-			 * value here will always equal the @probed_size).
-			 *
-			 * Note that if the value returned here is zero, then
-			 * this must be an old kernel which lacks the relevant
-			 * small-bar uAPI support (including
-			 * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
-			 * such systems we should never actually end up with a
-			 * small BAR configuration, assuming we are able to load
-			 * the kernel module. Hence it should be safe to treat
-			 * this the same as when @probed_cpu_visible_size ==
-			 * @probed_size.
-			 */
-			__u64 probed_cpu_visible_size;
-
-			/**
-			 * @unallocated_cpu_visible_size: Estimate of CPU
-			 * visible memory remaining
-			 *
-			 * Note this is only tracked for
-			 * I915_MEMORY_CLASS_DEVICE regions (for other types the
-			 * value here will always equal the
-			 * @probed_cpu_visible_size).
-			 *
-			 * Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable
-			 * accounting.  Without this the value here will always
-			 * equal the @probed_cpu_visible_size. Note this is only
-			 * currently tracked for I915_MEMORY_CLASS_DEVICE
-			 * regions (for other types the value here will also
-			 * always equal the @probed_cpu_visible_size).
-			 *
-			 * If this is an older kernel the value here will be
-			 * zero, see also @probed_cpu_visible_size.
-			 */
-			__u64 unallocated_cpu_visible_size;
-		};
-	};
-};
-
-/**
- * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, with added
- * extension support using struct i915_user_extension.
- *
- * Note that new buffer flags should be added here, at least for the stuff that
- * is immutable. Previously we would have two ioctls, one to create the object
- * with gem_create, and another to apply various parameters, however this
- * creates some ambiguity for the params which are considered immutable. Also in
- * general we're phasing out the various SET/GET ioctls.
- */
-struct __drm_i915_gem_create_ext {
-	/**
-	 * @size: Requested size for the object.
-	 *
-	 * The (page-aligned) allocated size for the object will be returned.
-	 *
-	 * Note that for some devices we have might have further minimum
-	 * page-size restrictions (larger than 4K), like for device local-memory.
-	 * However in general the final size here should always reflect any
-	 * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
-	 * extension to place the object in device local-memory. 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.
-	 */
-	__u64 size;
-
-	/**
-	 * @handle: Returned handle for the object.
-	 *
-	 * Object handles are nonzero.
-	 */
-	__u32 handle;
-
-	/**
-	 * @flags: Optional flags.
-	 *
-	 * Supported values:
-	 *
-	 * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the kernel that
-	 * the object will need to be accessed via the CPU.
-	 *
-	 * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and only
-	 * strictly required on configurations where some subset of the device
-	 * memory is directly visible/mappable through the CPU (which we also
-	 * call small BAR), like on some DG2+ systems. Note that this is quite
-	 * undesirable, but due to various factors like the client CPU, BIOS etc
-	 * it's something we can expect to see in the wild. See
-	 * &__drm_i915_memory_region_info.probed_cpu_visible_size for how to
-	 * determine if this system applies.
-	 *
-	 * Note that one of the placements MUST be I915_MEMORY_CLASS_SYSTEM, to
-	 * ensure the kernel can always spill the allocation to system memory,
-	 * if the object can't be allocated in the mappable part of
-	 * I915_MEMORY_CLASS_DEVICE.
-	 *
-	 * Also note that since the kernel only supports flat-CCS on objects
-	 * that can *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore
-	 * don't support I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS together with
-	 * flat-CCS.
-	 *
-	 * Without this hint, the kernel will assume that non-mappable
-	 * I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the
-	 * kernel can still migrate the object to the mappable part, as a last
-	 * resort, if userspace ever CPU faults this object, but this might be
-	 * expensive, and so ideally should be avoided.
-	 *
-	 * On older kernels which lack the relevant small-bar uAPI support (see
-	 * also &__drm_i915_memory_region_info.probed_cpu_visible_size),
-	 * usage of the flag will result in an error, but it should NEVER be
-	 * possible to end up with a small BAR configuration, assuming we can
-	 * also successfully load the i915 kernel module. In such cases the
-	 * entire I915_MEMORY_CLASS_DEVICE region will be CPU accessible, and as
-	 * such there are zero restrictions on where the object can be placed.
-	 */
-#define I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS (1 << 0)
-	__u32 flags;
-
-	/**
-	 * @extensions: The chain of extensions to apply to this object.
-	 *
-	 * This will be useful in the future when we need to support several
-	 * different extensions, and we need to apply more than one when
-	 * creating the object. See struct i915_user_extension.
-	 *
-	 * If we don't supply any extensions then we get the same old gem_create
-	 * behaviour.
-	 *
-	 * For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see
-	 * struct drm_i915_gem_create_ext_memory_regions.
-	 *
-	 * For I915_GEM_CREATE_EXT_PROTECTED_CONTENT usage see
-	 * struct drm_i915_gem_create_ext_protected_content.
-	 */
-#define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0
-#define I915_GEM_CREATE_EXT_PROTECTED_CONTENT 1
-	__u64 extensions;
-};
diff --git a/Documentation/gpu/rfc/i915_small_bar.rst b/Documentation/gpu/rfc/i915_small_bar.rst
deleted file mode 100644
index d6c03ce3b862b..0000000000000
--- a/Documentation/gpu/rfc/i915_small_bar.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-==========================
-I915 Small BAR RFC Section
-==========================
-Starting from DG2 we will have resizable BAR support for device local-memory(i.e
-I915_MEMORY_CLASS_DEVICE), but in some cases the final BAR size might still be
-smaller than the total probed_size. In such cases, only some subset of
-I915_MEMORY_CLASS_DEVICE will be CPU accessible(for example the first 256M),
-while the remainder is only accessible via the GPU.
-
-I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS flag
-----------------------------------------------
-New gem_create_ext flag to tell the kernel that a BO will require CPU access.
-This becomes important when placing an object in I915_MEMORY_CLASS_DEVICE, where
-underneath the device has a small BAR, meaning only some portion of it is CPU
-accessible. Without this flag the kernel will assume that CPU access is not
-required, and prioritize using the non-CPU visible portion of
-I915_MEMORY_CLASS_DEVICE.
-
-.. kernel-doc:: Documentation/gpu/rfc/i915_small_bar.h
-   :functions: __drm_i915_gem_create_ext
-
-probed_cpu_visible_size attribute
----------------------------------
-New struct__drm_i915_memory_region attribute which returns the total size of the
-CPU accessible portion, for the particular region. This should only be
-applicable for I915_MEMORY_CLASS_DEVICE. We also report the
-unallocated_cpu_visible_size, alongside the unallocated_size.
-
-Vulkan will need this as part of creating a separate VkMemoryHeap with the
-VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT set, to represent the CPU visible portion,
-where the total size of the heap needs to be known. It also wants to be able to
-give a rough estimate of how memory can potentially be allocated.
-
-.. kernel-doc:: Documentation/gpu/rfc/i915_small_bar.h
-   :functions: __drm_i915_memory_region_info
-
-Error Capture restrictions
---------------------------
-With error capture we have two new restrictions:
-
-    1) Error capture is best effort on small BAR systems; if the pages are not
-    CPU accessible, at the time of capture, then the kernel is free to skip
-    trying to capture them.
-
-    2) On discrete and newer integrated platforms we now reject error capture
-    on recoverable contexts. In the future the kernel may want to blit during
-    error capture, when for example something is not currently CPU accessible.
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 1256dde0fb3b1..3ab666616c3c5 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -24,9 +24,5 @@ host such documentation:
 
     i915_scheduler.rst
 
-.. toctree::
-
-    i915_small_bar.rst
-
 .. toctree::
     color_pipeline.rst
-- 
2.53.0

[PATCH 4/4] drm/doc/rfc: Remove i915_scheduler item.

[Maarten Lankhorst]

I've seen no updates since e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface")

Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
 Documentation/gpu/rfc/i915_scheduler.rst | 152 -----------------------
 Documentation/gpu/rfc/index.rst          |   4 -
 2 files changed, 156 deletions(-)
 delete mode 100644 Documentation/gpu/rfc/i915_scheduler.rst

diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst
deleted file mode 100644
index 2974525f0ac54..0000000000000
--- a/Documentation/gpu/rfc/i915_scheduler.rst
+++ /dev/null
@@ -1,152 +0,0 @@
-=========================================
-I915 GuC Submission/DRM Scheduler Section
-=========================================
-
-Upstream plan
-=============
-For upstream the overall plan for landing GuC submission and integrating the
-i915 with the DRM scheduler is:
-
-* Merge basic GuC submission
-	* Basic submission support for all gen11+ platforms
-	* Not enabled by default on any current platforms but can be enabled via
-	  modparam enable_guc
-	* Lots of rework will need to be done to integrate with DRM scheduler so
-	  no need to nit pick everything in the code, it just should be
-	  functional, no major coding style / layering errors, and not regress
-	  execlists
-	* Update IGTs / selftests as needed to work with GuC submission
-	* Enable CI on supported platforms for a baseline
-	* Rework / get CI heathly for GuC submission in place as needed
-* Merge new parallel submission uAPI
-	* Bonding uAPI completely incompatible with GuC submission, plus it has
-	  severe design issues in general, which is why we want to retire it no
-	  matter what
-	* New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step
-	  which configures a slot with N contexts
-	* After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to
-	  a slot in a single execbuf IOCTL and the batches run on the GPU in
-	  parallel
-	* Initially only for GuC submission but execlists can be supported if
-	  needed
-* Convert the i915 to use the DRM scheduler
-	* GuC submission backend fully integrated with DRM scheduler
-		* All request queues removed from backend (e.g. all backpressure
-		  handled in DRM scheduler)
-		* Resets / cancels hook in DRM scheduler
-		* Watchdog hooks into DRM scheduler
-		* Lots of complexity of the GuC backend can be pulled out once
-		  integrated with DRM scheduler (e.g. state machine gets
-		  simpler, locking gets simpler, etc...)
-	* Execlists backend will minimum required to hook in the DRM scheduler
-		* Legacy interface
-		* Features like timeslicing / preemption / virtual engines would
-		  be difficult to integrate with the DRM scheduler and these
-		  features are not required for GuC submission as the GuC does
-		  these things for us
-		* ROI low on fully integrating into DRM scheduler
-		* Fully integrating would add lots of complexity to DRM
-		  scheduler
-	* Port i915 priority inheritance / boosting feature in DRM scheduler
-		* Used for i915 page flip, may be useful to other DRM drivers as
-		  well
-		* Will be an optional feature in the DRM scheduler
-	* Remove in-order completion assumptions from DRM scheduler
-		* Even when using the DRM scheduler the backends will handle
-		  preemption, timeslicing, etc... so it is possible for jobs to
-		  finish out of order
-	* Pull out i915 priority levels and use DRM priority levels
-	* Optimize DRM scheduler as needed
-
-TODOs for GuC submission upstream
-=================================
-
-* Need an update to GuC firmware / i915 to enable error state capture
-* Open source tool to decode GuC logs
-* Public GuC spec
-
-New uAPI for basic GuC submission
-=================================
-No major changes are required to the uAPI for basic GuC submission. The only
-change is a new scheduler attribute: I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP.
-This attribute indicates the 2k i915 user priority levels are statically mapped
-into 3 levels as follows:
-
-* -1k to -1 Low priority
-* 0 Medium priority
-* 1 to 1k High priority
-
-This is needed because the GuC only has 4 priority bands. The highest priority
-band is reserved with the kernel. This aligns with the DRM scheduler priority
-levels too.
-
-Spec references:
-----------------
-* https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt
-* https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap5.html#devsandqueues-priority
-* https://spec.oneapi.com/level-zero/latest/core/api.html#ze-command-queue-priority-t
-
-New parallel submission uAPI
-============================
-The existing bonding uAPI is completely broken with GuC submission because
-whether a submission is a single context submit or parallel submit isn't known
-until execbuf time activated via the I915_SUBMIT_FENCE. To submit multiple
-contexts in parallel with the GuC the context must be explicitly registered with
-N contexts and all N contexts must be submitted in a single command to the GuC.
-The GuC interfaces do not support dynamically changing between N contexts as the
-bonding uAPI does. Hence the need for a new parallel submission interface. Also
-the legacy bonding uAPI is quite confusing and not intuitive at all. Furthermore
-I915_SUBMIT_FENCE is by design a future fence, so not really something we should
-continue to support.
-
-The new parallel submission uAPI consists of 3 parts:
-
-* Export engines logical mapping
-* A 'set_parallel' extension to configure contexts for parallel
-  submission
-* Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
-
-Export engines logical mapping
-------------------------------
-Certain use cases require BBs to be placed on engine instances in logical order
-(e.g. split-frame on gen11+). The logical mapping of engine instances can change
-based on fusing. Rather than making UMDs be aware of fusing, simply expose the
-logical mapping with the existing query engine info IOCTL. Also the GuC
-submission interface currently only supports submitting multiple contexts to
-engines in logical order which is a new requirement compared to execlists.
-Lastly, all current platforms have at most 2 engine instances and the logical
-order is the same as uAPI order. This will change on platforms with more than 2
-engine instances.
-
-A single bit will be added to drm_i915_engine_info.flags indicating that the
-logical instance has been returned and a new field,
-drm_i915_engine_info.logical_instance, returns the logical instance.
-
-A 'set_parallel' extension to configure contexts for parallel submission
-------------------------------------------------------------------------
-The 'set_parallel' extension configures a slot for parallel submission of N BBs.
-It is a setup step that must be called before using any of the contexts. See
-I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE or I915_CONTEXT_ENGINES_EXT_BOND for
-similar existing examples. Once a slot is configured for parallel submission the
-execbuf2 IOCTL can be called submitting N BBs in a single IOCTL. Initially only
-supports GuC submission. Execlists supports can be added later if needed.
-
-Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and
-drm_i915_context_engines_parallel_submit to the uAPI to implement this
-extension.
-
-.. c:namespace-push:: rfc
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-        :functions: i915_context_engines_parallel_submit
-
-.. c:namespace-pop::
-
-Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
--------------------------------------------------------------------
-Contexts that have been configured with the 'set_parallel' extension can only
-submit N BBs in a single execbuf2 IOCTL. The BBs are either the last N objects
-in the drm_i915_gem_exec_object2 list or the first N if I915_EXEC_BATCH_FIRST is
-set. The number of BBs is implicit based on the slot submitted and how it has
-been configured by 'set_parallel' or other extensions. No uAPI changes are
-required to the execbuf2 IOCTL.
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 3ab666616c3c5..975b7094e259a 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -20,9 +20,5 @@ host such documentation:
 
     gpusvm.rst
 
-.. toctree::
-
-    i915_scheduler.rst
-
 .. toctree::
     color_pipeline.rst
-- 
2.53.0

Re: [PATCH 0/4] drm/doc: Remove obsolete RFC docs related to i915.

[Rodrigo Vivi]

On Mon, Apr 20, 2026 at 10:33:18AM +0200, Maarten Lankhorst wrote:
> I believe small_bar has been implemented, as is gem_lmem.
> 
> xe has implemented GuC submission and VM_BIND, but realistically
> this will never happen for i915.
> 
> Either way, those RFC's are completed, and can be removed.
> 
> Maarten Lankhorst (4):
>   drm/doc/rfc: Remove i915_gem_lmem.rst
>   drm/doc/rfc: Remove i915_vm_bind.
>   drm/doc/rfc: Remove i915_small_bar rfc.
>   drm/doc/rfc: Remove i915_scheduler item.

Thanks for the clean-up.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> 
>  Documentation/gpu/rfc/i915_gem_lmem.rst  |  22 --
>  Documentation/gpu/rfc/i915_scheduler.rst | 152 ------------
>  Documentation/gpu/rfc/i915_small_bar.h   | 189 ---------------
>  Documentation/gpu/rfc/i915_small_bar.rst |  47 ----
>  Documentation/gpu/rfc/i915_vm_bind.h     | 290 -----------------------
>  Documentation/gpu/rfc/i915_vm_bind.rst   | 245 -------------------
>  Documentation/gpu/rfc/index.rst          |  18 +-
>  7 files changed, 1 insertion(+), 962 deletions(-)
>  delete mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
>  delete mode 100644 Documentation/gpu/rfc/i915_scheduler.rst
>  delete mode 100644 Documentation/gpu/rfc/i915_small_bar.h
>  delete mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
>  delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
>  delete mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst
> 
> -- 
> 2.53.0
> 

Claude review: drm/doc: Remove obsolete RFC docs related to i915.

[Claude Code Review Bot]

Overall Series Review

Subject: drm/doc: Remove obsolete RFC docs related to i915.
Author: Maarten Lankhorst <dev@lankhorst.se>
Patches: 6
Reviewed: 2026-04-23T10:10:53.144524

---

This is a straightforward documentation cleanup series that removes four obsolete RFC documents from `Documentation/gpu/rfc/`. The justification is sound: these RFCs describe i915 features that have either been implemented and shipped (lmem, small_bar, GuC scheduler) or superseded by the xe driver (vm_bind). The RFC section is explicitly meant to be temporary — `index.rst` itself says "Once the code has landed move all the documentation to the right places in the main core, helper or driver sections."

The series is low risk (documentation-only, no code changes) and logically structured with one patch per RFC removal. Each commit message provides adequate justification referencing either specific landed commits or the xe driver as the successor implementation.

**Minor nit on the series**: After all four patches are applied, the final `index.rst` has two remaining `.. toctree::` directives (for `gpusvm.rst` and `color_pipeline.rst`) that could be consolidated into one, but that's a pre-existing style issue and not in scope here.

No objections to this series.

---

---
Generated by Claude Code Patch Reviewer

Claude review: drm/doc/rfc: Remove i915_gem_lmem.rst

[Claude Code Review Bot]

Patch Review

**Reviewed-by worthy**: Yes.

The RFC described the DG1/LMEM upstream plan (TTM conversion, pciid addition, etc.) — all of which is long since completed. DG2 is fully supported in i915, and the xe driver handles newer discrete GPU memory management.

This patch also fixes a pre-existing missing newline at end of file in `index.rst`:

```diff
-    color_pipeline.rst
\ No newline at end of file
+    color_pipeline.rst
```

This is a good drive-by fix but isn't mentioned in the commit message. Very minor — not worth blocking over.

No issues.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/doc/rfc: Remove i915_vm_bind.

[Claude Code Review Bot]

Patch Review

**Reviewed-by worthy**: Yes.

The commit message correctly notes that i915 supports soft pinning and the xe driver was created to properly handle VM_BIND. The removed RFC described a VM_BIND/execbuf3 design that was never implemented in i915. The `.h` and `.rst` files being removed are RFC proposal documents, not actual UAPI headers, so there's no risk of breaking anything.

**Minor nit**: The subject line has a trailing period (`Remove i915_vm_bind.`) which is inconsistent with patches 1 and 4 that don't have one. Purely cosmetic.

No issues.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/doc/rfc: Remove i915_small_bar rfc.

[Claude Code Review Bot]

Patch Review

**Reviewed-by worthy**: Yes.

The commit message references the specific commits that implemented the small BAR feature:
- `525e93f6317a ("drm/i915/uapi: add NEEDS_CPU_ACCESS hint")`
- `3f4309cbdc84 ("drm/i915/uapi: add probed_cpu_visible_size")`

The RFC described the `I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS` flag and `probed_cpu_visible_size` attribute, both of which are now in the actual UAPI headers. The RFC has served its purpose.

The cautious "Probably done" in the commit message is honest — but looking at the RFC content, both key features it describes (the `NEEDS_CPU_ACCESS` flag and `probed_cpu_visible_size`) are referenced by the cited commits. This is done.

No issues.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/doc/rfc: Remove i915_scheduler item.

[Claude Code Review Bot]

Patch Review

**Reviewed-by worthy**: Yes.

The commit message notes no updates since `e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface")`. The RFC described the plan for GuC submission and DRM scheduler integration in i915. GuC submission has landed, and the xe driver has taken over for future GPU submission work. The remaining TODO items (DRM scheduler integration for execlists, priority inheritance porting, etc.) are unlikely to ever be completed for i915.

No issues.

---
Generated by Claude Code Patch Reviewer