summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorRodrigo Vivi <rodrigo.vivi@intel.com>2023-12-01 05:21:54 +0100
committerRodrigo Vivi <rodrigo.vivi@intel.com>2023-12-07 17:00:58 +0100
commit34e64dd192071c3159c118331f87c66dffa0f9c9 (patch)
tree012fd1060bafb77525b7286001b98f498aa09943 /Documentation
parentdrm/doc/rfc: Move Xe 'ASYNC VM_BIND' to the 'completed' section (diff)
downloadlinux-34e64dd192071c3159c118331f87c66dffa0f9c9.tar.xz
linux-34e64dd192071c3159c118331f87c66dffa0f9c9.zip
drm/doc/rfc: Move userptr integration and vm_bind to the 'completed' section
The must-have part of the documentation was already added to the existing /gpu/drm-vm-bind-async. The other extra discussion around GPUVM helpers are currently active in the community. None of those discussion should block Xe since documentation, specially around locking was completed in a community consensus. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231201042158.80009-5-rodrigo.vivi@intel.com Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/gpu/rfc/xe.rst64
1 files changed, 32 insertions, 32 deletions
diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
index 87dd620aea59..cfff8a59a876 100644
--- a/Documentation/gpu/rfc/xe.rst
+++ b/Documentation/gpu/rfc/xe.rst
@@ -70,38 +70,6 @@ When the time comes for Xe, the protection will be lifted on Xe and kept in i915
Xe – Pre-Merge Goals - Work-in-Progress
=======================================
-Userptr integration and vm_bind
--------------------------------
-Different drivers implement different ways of dealing with execution of userptr.
-With multiple drivers currently introducing support to VM_BIND, the goal is to
-aim for a DRM consensus on what’s the best way to have that support. To some
-extent this is already getting addressed itself with the GPUVA where likely the
-userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr.
-However, there are more aspects around the rules for that and the usage of
-mmu_notifiers, locking and other aspects.
-
-This task here has the goal of introducing a documentation of the basic rules.
-
-The documentation *needs* to first live in this document (API session below) and
-then moved to another more specific document or at Xe level or at DRM level.
-
-Documentation should include:
-
- * The userptr part of the VM_BIND api.
-
- * Locking, including the page-faulting case.
-
- * O(1) complexity under VM_BIND.
-
-The document is now included in the drm documentation :doc:`here </gpu/drm-vm-bind-async>`.
-
-Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when
-the second driver supporting VM_BIND+userptr appears. Details to be defined when
-the time comes.
-
-The DRM GPUVM helpers do not yet include the userptr parts, but discussions
-about implementing them are ongoing.
-
Display integration with i915
-----------------------------
In order to share the display code with the i915 driver so that there is maximum
@@ -139,6 +107,38 @@ Xe – uAPI high level overview
Xe – Pre-Merge Goals - Completed
================================
+Userptr integration and vm_bind
+-------------------------------
+Different drivers implement different ways of dealing with execution of userptr.
+With multiple drivers currently introducing support to VM_BIND, the goal is to
+aim for a DRM consensus on what’s the best way to have that support. To some
+extent this is already getting addressed itself with the GPUVA where likely the
+userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr.
+However, there are more aspects around the rules for that and the usage of
+mmu_notifiers, locking and other aspects.
+
+This task here has the goal of introducing a documentation of the basic rules.
+
+The documentation *needs* to first live in this document (API session below) and
+then moved to another more specific document or at Xe level or at DRM level.
+
+Documentation should include:
+
+ * The userptr part of the VM_BIND api.
+
+ * Locking, including the page-faulting case.
+
+ * O(1) complexity under VM_BIND.
+
+The document is now included in the drm documentation :doc:`here </gpu/drm-vm-bind-async>`.
+
+Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when
+the second driver supporting VM_BIND+userptr appears. Details to be defined when
+the time comes.
+
+The DRM GPUVM helpers do not yet include the userptr parts, but discussions
+about implementing them are ongoing.
+
ASYNC VM_BIND
-------------
Although having a common DRM level IOCTL for VM_BIND is not a requirement to get