drm/doc/rfc: Mark long running workload as complete.

No DRM scheduler changes required, drivers just return NULL in run_job
vfunc.

The rough consensus is that no helper or extra scaffolding is needed
around long-running jobs and no further changes to drm-scheduler.

At least for now. Other drivers that currently do long-running workloads
have no plat to use drm-scheduler. Besides, the current consensus is
that this solution of simply returning NULL to the run_job function should
work without extra code duplication or complication.

On top of that, this item was already a non-blocking one for upstreaming Xe,
so let's move that to the 'Completed' section and revisit the long-running
solution as a community after Xe is integrated in DRM.

Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231201042158.80009-2-rodrigo.vivi@intel.com
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
index ceb21219d52ecdbcbae194d2a5ea7e25a54fb49c..2a513232761782dcec2aaf5528dfd5f72df4a813 100644 (file)
--- a/Documentation/gpu/rfc/xe.rst
+++ b/Documentation/gpu/rfc/xe.rst
@@ -132,21 +132,6 @@ the time comes.
 The DRM GPUVM helpers do not yet include the userptr parts, but discussions
 about implementing them are ongoing.
 
-Long running compute: minimal data structure/scaffolding
---------------------------------------------------------
-The generic scheduler code needs to include the handling of endless compute
-contexts, with the minimal scaffolding for preempt-ctx fences (probably on the
-drm_sched_entity) and making sure drm_scheduler can cope with the lack of job
-completion fence.
-
-The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with
-this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any
-drm driver, including Xe, could re-use and add their own individual needs on top
-in a next stage. However, this should not block the initial merge.
-
-This is a non-blocker item since the driver without the support for the long
-running compute enabled is not a showstopper.
-
 Display integration with i915
 -----------------------------
 In order to share the display code with the i915 driver so that there is maximum
@@ -184,6 +169,18 @@ Xe – uAPI high level overview
 Xe – Pre-Merge Goals - Completed
 ================================
 
+Long running compute: minimal data structure/scaffolding
+--------------------------------------------------------
+The generic scheduler code needs to include the handling of endless compute
+contexts, with the minimal scaffolding for preempt-ctx fences (probably on the
+drm_sched_entity) and making sure drm_scheduler can cope with the lack of job
+completion fence.
+
+The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with
+this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any
+drm driver, including Xe, could re-use and add their own individual needs on top
+in a next stage. However, this should not block the initial merge.
+
 Dev_coredump
 ------------