diff options
Diffstat (limited to 'Documentation/gpu/i915.rst')
| -rw-r--r-- | Documentation/gpu/i915.rst | 62 |
1 files changed, 35 insertions, 27 deletions
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 60ea21734902..eba09c3ddce4 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -35,10 +35,10 @@ Interrupt Handling :functions: intel_irq_init intel_irq_init_hw intel_hpd_init .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c - :functions: intel_runtime_pm_disable_interrupts + :functions: intel_irq_suspend .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c - :functions: intel_runtime_pm_enable_interrupts + :functions: intel_irq_resume Intel GVT-g Guest Support(vGPU) ------------------------------- @@ -112,10 +112,10 @@ panel self refresh. Atomic Plane Helpers -------------------- -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c :doc: atomic plane helpers -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c :internal: Asynchronous Page Flip @@ -150,7 +150,7 @@ High Definition Audio .. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c :internal: -.. kernel-doc:: include/drm/i915_component.h +.. kernel-doc:: include/drm/intel/i915_component.h :internal: Intel HDMI LPE Audio Support @@ -204,6 +204,18 @@ DMC Firmware Support .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c :internal: +DMC Flip Queue +-------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_flipq.c + :doc: DMC Flip Queue + +DMC wakelock support +-------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c + :doc: DMC wakelock support + Video BIOS Table (VBT) ---------------------- @@ -267,19 +279,22 @@ i915 driver. Intel GPU Basics ---------------- -An Intel GPU has multiple engines. There are several engine types. - -- RCS engine is for rendering 3D and performing compute, this is named - `I915_EXEC_RENDER` in user space. -- BCS is a blitting (copy) engine, this is named `I915_EXEC_BLT` in user - space. -- VCS is a video encode and decode engine, this is named `I915_EXEC_BSD` - in user space -- VECS is video enhancement engine, this is named `I915_EXEC_VEBOX` in user - space. -- The enumeration `I915_EXEC_DEFAULT` does not refer to specific engine; - instead it is to be used by user space to specify a default rendering - engine (for 3D) that may or may not be the same as RCS. +An Intel GPU has multiple engines. There are several engine types: + +- Render Command Streamer (RCS). An engine for rendering 3D and + performing compute. +- Blitting Command Streamer (BCS). An engine for performing blitting and/or + copying operations. +- Video Command Streamer. An engine used for video encoding and decoding. Also + sometimes called 'BSD' in hardware documentation. +- Video Enhancement Command Streamer (VECS). An engine for video enhancement. + Also sometimes called 'VEBOX' in hardware documentation. +- Compute Command Streamer (CCS). An engine that has access to the media and + GPGPU pipelines, but not the 3D pipeline. +- Graphics Security Controller (GSCCS). A dedicated engine for internal + communication with GSC controller on security related tasks like + High-bandwidth Digital Content Protection (HDCP), Protected Xe Path (PXP), + and HuC firmware authentication. The Intel GPU family is a family of integrated GPU's using Unified Memory Access. For having the GPU "do work", user space will feed the @@ -304,10 +319,10 @@ reads of following commands. Actions issued between different contexts and the only way to synchronize across contexts (even from the same file descriptor) is through the use of fences. At least as far back as Gen4, also have that a context carries with it a GPU HW context; -the HW context is essentially (most of atleast) the state of a GPU. +the HW context is essentially (most of at least) the state of a GPU. In addition to the ordering guarantees, the kernel will restore GPU state via HW context when commands are issued to a context, this saves -user space the need to restore (most of atleast) the GPU state at the +user space the need to restore (most of at least) the GPU state at the start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) to identify what context to use with the command. @@ -343,8 +358,6 @@ Locking Guidelines #. All locking rules and interface contracts with cross-driver interfaces (dma-buf, dma_fence) need to be followed. -#. No struct_mutex anywhere in the code - #. dma_resv will be the outermost lock (when needed) and ww_acquire_ctx is to be hoisted at highest level and passed down within i915_gem_ctx in the call chain @@ -352,11 +365,6 @@ Locking Guidelines #. While holding lru/memory manager (buddy, drm_mm, whatever) locks system memory allocations are not allowed - * Enforce this by priming lockdep (with fs_reclaim). If we - allocate memory while holding these looks we get a rehash - of the shrinker vs. struct_mutex saga, and that would be - real bad. - #. Do not nest different lru/memory manager locks within each other. Take them in turn to update memory allocations, relying on the object’s dma_resv ww_mutex to serialize against other operations. |