diff options
Diffstat (limited to 'Documentation/gpu')
51 files changed, 1104 insertions, 364 deletions
diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst index 033167025fcc..d553dd599c96 100644 --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -233,8 +233,15 @@ we have a dedicated glossary for Display Core at TC Texture Cache + TCC + Texture Cache per Channel - L2 cache attached to the memory channels. + May be used when shader cores are accessing memory. + Despite "Texture" in the name, this is used by any kind of memory access. + TCCs may be mapped to TCPs, depending on the architecture. + TCP (AMDGPU) - Texture Cache per Pipe. Even though the name "Texture" is part of this + Texture Cache per Pipe - L1 cache attached to each CU. + Even though the name "Texture" is part of this acronym, the TCP represents the path to memory shaders; i.e., it is not related to texture. The name is a leftover from older designs where shader stages had different cache designs; it refers to the L1 cache in older diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst index b269ff3f7a54..f6de9e7779e2 100644 --- a/Documentation/gpu/amdgpu/display/display-manager.rst +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -32,6 +32,9 @@ Interrupts .. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_display.c + :functions: amdgpu_display_hotplug_work_func + Atomic Implementation ===================== @@ -178,3 +181,9 @@ following path: 2. On DC interface, :c:type:`struct mpcc_blnd_cfg <mpcc_blnd_cfg>` programs the MPCC blend configuration considering the :c:type:`dc_plane_info <dc_plane_info>` input from DPP. + +Display Properties +================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_display.c + :doc: property for adaptive backlight modulation diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst index 8732084186a4..b2ab182236ef 100644 --- a/Documentation/gpu/amdgpu/index.rst +++ b/Documentation/gpu/amdgpu/index.rst @@ -23,3 +23,4 @@ Next (GCN), Radeon DNA (RDNA), and Compute DNA (CDNA) architectures. debugfs process-isolation amdgpu-glossary + ptl diff --git a/Documentation/gpu/amdgpu/ptl.rst b/Documentation/gpu/amdgpu/ptl.rst new file mode 100644 index 000000000000..c7f16dea7954 --- /dev/null +++ b/Documentation/gpu/amdgpu/ptl.rst @@ -0,0 +1,94 @@ +======================================= +Peak Tops Limiter (PTL) sysfs Interface +======================================= + +Overview +-------- +The Peak Tops Limiter (PTL) sysfs interface enables users to control and +configure the PTL feature for each GPU individually. All PTL-related +sysfs files are located under `/sys/class/drm/cardX/device/ptl/`, where +`X` is the GPU index. Through these files, users can enable or disable +PTL, set preferred data formats, and query supported formats for each GPU. + +PTL sysfs files +---------------- +The following files are available under `/sys/class/drm/cardX/device/ptl/`: + +- `ptl_enable` +- `ptl_format` +- `ptl_supported_formats` + +PTL Enable/Disable +------------------ +File: `ptl_enable` +Type: Read/Write (rw) + +Read: Returns the current PTL status as a string: `enabled` if PTL +is active, or `disabled` if inactive. + +Write: + +- Write `1` or `enabled` to enable PTL +- Write `0` or `disabled` to disable PTL + +Examples:: + + # Query PTL status + cat /sys/class/drm/card1/device/ptl/ptl_enable + # Output: enabled + + # Enable PTL + sudo bash -c "echo 1 > /sys/class/drm/card1/device/ptl/ptl_enable" + + # Disable PTL + sudo bash -c "echo 0 > /sys/class/drm/card1/device/ptl/ptl_enable" + +PTL Format (Preferred Data Formats) +----------------------------------- +File: `ptl_format` +Type: Read/Write (rw) + +Read: Returns the two preferred formats, e.g. `I8,F32`. + +Write: Accepts two formats separated by a comma, e.g. `I8,F32`. + +- Both formats must be supported and different. +- If an invalid format is provided (not supported, or both formats are the + same), the driver will return "write error: Invalid argument". + +Examples:: + + # Query PTL formats + cat /sys/class/drm/card1/device/ptl/ptl_format + # Output: I8,F32 + + # Set PTL formats + sudo bash -c "echo I8,F32 > /sys/class/drm/card1/device/ptl/ptl_format" + +Supported Formats +----------------- +File: `ptl_supported_formats` +Type: Read-only (r) + +Read: Returns a comma-separated list of supported formats, e.g. +`I8,F16,BF16,F32,F64`. + +Example:: + + # Check supported formats + cat /sys/class/drm/card1/device/ptl/ptl_supported_formats + # Output: I8,F16,BF16,F32,F64 + +Behavioral Notes +---------------- +- PTL formats can only be set when PTL is enabled. +- If PTL is disabled, `ptl_format` returns `N/A`. +- Only two formats can be set at a time, and they must be from the supported set and different.. +- All commands support per-GPU targeting. +- Root permission is required to enable/disable PTL or change formats. +- If the hardware does not support PTL, the PTL sysfs directory will not + be created. + +Implementation +-------------- +The PTL sysfs nodes are implemented in `drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c`. diff --git a/Documentation/gpu/automated_testing.rst b/Documentation/gpu/automated_testing.rst index 62aa3ede02a5..8a7328aef10e 100644 --- a/Documentation/gpu/automated_testing.rst +++ b/Documentation/gpu/automated_testing.rst @@ -99,7 +99,8 @@ How to enable automated testing on your tree ============================================ 1. Create a Linux tree in https://gitlab.freedesktop.org/ if you don't have one -yet +yet, by forking https://gitlab.freedesktop.org/drm/kernel (this allows GitLab +to internally track that these are the same git objects). 2. In your kernel repo's configuration (eg. https://gitlab.freedesktop.org/janedoe/linux/-/settings/ci_cd), change the diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index 1f15a8ca1265..627fc68c7a21 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -2,6 +2,8 @@ DRM Driver uAPI =============== +.. contents:: + drm/i915 uAPI ============= diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index 2e13e0ad7e88..20d2c454aa1d 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -8,6 +8,7 @@ GPU Driver Documentation amdgpu/index i915 imagination/index + intel-display/index mcde meson nouveau diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 94f93fd3b8a0..a3ce25a36f1d 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -18,6 +18,8 @@ event handling, memory management, output management, framebuffer management, command submission & fencing, suspend/resume support, and DMA services. +.. contents:: + Driver Initialization ===================== diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 781129f78b06..94cfc26acecc 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -33,6 +33,8 @@ There are a few areas these helpers can grouped into: pipeline: Planes, handling rectangles for visibility checking and scissoring, flip queues and assorted bits. +.. contents:: + Modeset Helper Reference for Common Vtables =========================================== @@ -104,18 +106,6 @@ VBLANK Helper Reference .. kernel-doc:: drivers/gpu/drm/drm_vblank_helper.c :export: -Simple KMS Helper Reference -=========================== - -.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c - :doc: overview - -.. kernel-doc:: include/drm/drm_simple_kms_helper.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c - :export: - fbdev Helper Functions Reference ================================ @@ -181,6 +171,12 @@ Bridge Operations .. kernel-doc:: drivers/gpu/drm/drm_bridge.c :doc: bridge operations +Bridge Chain Format Selection +----------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_bridge.c + :doc: bridge chain format selection + Bridge Connector Helper ----------------------- diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 2292e65f044c..0dd440a14946 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -1,3 +1,6 @@ + +.. _drm-kms: + ========================= Kernel Mode Setting (KMS) ========================= @@ -15,6 +18,8 @@ be setup by initializing the following fields. - struct drm_mode_config_funcs \*funcs; Mode setting functions. +.. contents:: + Overview ======== @@ -206,11 +211,11 @@ Atomic Mode Setting style=dashed label="Free-standing state" - "drm_atomic_state" -> "duplicated drm_plane_state A" - "drm_atomic_state" -> "duplicated drm_plane_state B" - "drm_atomic_state" -> "duplicated drm_crtc_state" - "drm_atomic_state" -> "duplicated drm_connector_state" - "drm_atomic_state" -> "duplicated driver private state" + "drm_atomic_commit" -> "duplicated drm_plane_state A" + "drm_atomic_commit" -> "duplicated drm_plane_state B" + "drm_atomic_commit" -> "duplicated drm_crtc_state" + "drm_atomic_commit" -> "duplicated drm_connector_state" + "drm_atomic_commit" -> "duplicated driver private state" } subgraph cluster_current { @@ -230,7 +235,7 @@ Atomic Mode Setting "driver private object" -> "driver private state" } - "drm_atomic_state" -> "drm_device" [label="atomic_commit"] + "drm_atomic_commit" -> "drm_device" [label="atomic_commit"] "duplicated drm_plane_state A" -> "drm_device"[style=invis] } @@ -265,7 +270,7 @@ Taken all together there's two consequences for the atomic design: drm_private_state<drm_private_state>`. - An atomic update is assembled and validated as an entirely free-standing pile - of structures within the :c:type:`drm_atomic_state <drm_atomic_state>` + of structures within the :c:type:`drm_atomic_commit <drm_atomic_commit>` container. Driver private state structures are also tracked in the same structure; see the next chapter. Only when a state is committed is it applied to the driver and modeset objects. This way rolling back an update boils down @@ -282,6 +287,12 @@ structure, ordering of committing state changes to hardware is sequenced using Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed coverage of specific topics. +Atomic State Lifetime +--------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_atomic.c + :doc: state lifetime + Handling Driver Private State ----------------------------- @@ -599,6 +610,12 @@ Color Management Properties .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c :doc: overview +Color Format Property +--------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_connector.c + :doc: Color format + Tile Group Property ------------------- diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index f22433470c76..2dea94f77d52 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -25,6 +25,8 @@ share it. GEM has simpler initialization and execution requirements than TTM, but has no video RAM management capabilities and is thus limited to UMA devices. +.. contents:: + The Translation Table Manager (TTM) =================================== @@ -526,8 +528,14 @@ DRM GPUVM Function References DRM Buddy Allocator =================== -DRM Buddy Function References ------------------------------ +Buddy Allocator Function References (GPU buddy) +----------------------------------------------- + +.. kernel-doc:: drivers/gpu/buddy.c + :export: + +DRM Buddy Specific Logging Function References +---------------------------------------------- .. kernel-doc:: drivers/gpu/drm/drm_buddy.c :export: diff --git a/Documentation/gpu/drm-ras.rst b/Documentation/gpu/drm-ras.rst new file mode 100644 index 000000000000..83c21853b74b --- /dev/null +++ b/Documentation/gpu/drm-ras.rst @@ -0,0 +1,113 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +============================ +DRM RAS over Generic Netlink +============================ + +The DRM RAS (Reliability, Availability, Serviceability) interface provides a +standardized way for GPU/accelerator drivers to expose error counters and +other reliability nodes to user space via Generic Netlink. This allows +diagnostic tools, monitoring daemons, or test infrastructure to query hardware +health in a uniform way across different DRM drivers. + +Key Goals: + +* Provide a standardized RAS solution for GPU and accelerator drivers, enabling + data center monitoring and reliability operations. +* Implement a single drm-ras Generic Netlink family to meet modern Netlink YAML + specifications and centralize all RAS-related communication in one namespace. +* Support a basic error counter interface, addressing the immediate, essential + monitoring needs. +* Offer a flexible, future-proof interface that can be extended to support + additional types of RAS data in the future. +* Allow multiple nodes per driver, enabling drivers to register separate + nodes for different IP blocks, sub-blocks, or other logical subdivisions + as applicable. + +.. contents:: + +Nodes +===== + +Nodes are logical abstractions representing an error type or error source within +the device. Currently, only error counter nodes is supported. + +Drivers are responsible for registering and unregistering nodes via the +`drm_ras_node_register()` and `drm_ras_node_unregister()` APIs. + +Node Management +------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_ras.c + :doc: DRM RAS Node Management +.. kernel-doc:: drivers/gpu/drm/drm_ras.c + :internal: + +Generic Netlink Usage +===================== + +The interface is implemented as a Generic Netlink family named ``drm-ras``. +User space tools can: + +* List registered nodes with the ``list-nodes`` command. +* List all error counters in an node with the ``get-error-counter`` command with ``node-id`` + as a parameter. +* Query specific error counter values with the ``get-error-counter`` command, using both + ``node-id`` and ``error-id`` as parameters. +* Clear specific error counters with the ``clear-error-counter`` command, using both + ``node-id`` and ``error-id`` as parameters. + +YAML-based Interface +-------------------- + +The interface is described in a YAML specification ``Documentation/netlink/specs/drm_ras.yaml`` + +This YAML is used to auto-generate user space bindings via +``tools/net/ynl/pyynl/ynl_gen_c.py``, and drives the structure of netlink +attributes and operations. + +Usage Notes +----------- + +* User space must first enumerate nodes to obtain their IDs. +* Node IDs or Node names can be used for all further queries, such as error counters. +* Error counters can be queried by either the Error ID or Error name. +* Query Parameters should be defined as part of the uAPI to ensure user interface stability. +* The interface supports future extension by adding new node types and + additional attributes. + +Example: List nodes using ynl + +.. code-block:: bash + + sudo ynl --family drm_ras --dump list-nodes + [{'device-name': '0000:03:00.0', + 'node-id': 0, + 'node-name': 'correctable-errors', + 'node-type': 'error-counter'}, + {'device-name': '0000:03:00.0', + 'node-id': 1, + 'node-name': 'uncorrectable-errors', + 'node-type': 'error-counter'}] + +Example: List all error counters using ynl + +.. code-block:: bash + + sudo ynl --family drm_ras --dump get-error-counter --json '{"node-id":0}' + [{'error-id': 1, 'error-name': 'error_name1', 'error-value': 0}, + {'error-id': 2, 'error-name': 'error_name2', 'error-value': 0}] + +Example: Query an error counter for a given node + +.. code-block:: bash + + sudo ynl --family drm_ras --do get-error-counter --json '{"node-id":0, "error-id":1}' + {'error-id': 1, 'error-name': 'error_name1', 'error-value': 0} + +Example: Clear an error counter for a given node + +.. code-block:: bash + + sudo ynl --family drm_ras --do clear-error-counter --json '{"node-id":0, "error-id":1}' + None diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index d98428a592f1..93df92c4ac8c 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -16,6 +16,8 @@ management, and output management. Cover generic ioctls and sysfs layout here. We only need high-level info, since man pages should cover the rest. +.. contents:: + libdrm Device Lookup ==================== @@ -118,6 +120,10 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs for the same thing co-existing. If we add a few more complete mistakes into the mix every year it would be entirely unmanageable. +The DRM subsystem has however no concern with independent closed-source +userspace implementations. To officialize that position, the DRM uAPI headers +are covered by the MIT license. + .. _drm_render_node: Render nodes @@ -438,14 +444,14 @@ following expectations. unknown consumer policy =============== ======================================== -The only exception to this is ``WEDGED=none``, which signifies that the device -was temporarily 'wedged' at some point but was recovered from driver context -using device specific methods like reset. No explicit recovery is expected from -the consumer in this case, but it can still take additional steps like gathering -telemetry information (devcoredump, syslog). This is useful because the first -hang is usually the most critical one which can result in consequential hangs or -complete wedging. +No Recovery +----------- +Here ``WEDGED=none`` signifies that no recovery is expected from the consumer +but it can still try to gather telemetry information (devcoredump, syslog) for +debug purpose in order to root cause the hang. This is useful because the first +hang is usually the most critical one which can result in consequential hangs +or complete wedging. Vendor Specific Recovery ------------------------ @@ -568,7 +574,7 @@ ENOSPC: EPERM/EACCES: Returned for an operation that is valid, but needs more privileges. E.g. root-only or much more common, DRM master-only operations return - this when called by unpriviledged clients. There's no clear + this when called by unprivileged clients. There's no clear difference between EACCES and EPERM. ENODEV: @@ -761,4 +767,4 @@ Stable uAPI events From ``drivers/gpu/drm/scheduler/gpu_scheduler_trace.h`` .. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler_trace.h - :doc: uAPI trace events
\ No newline at end of file + :doc: uAPI trace events diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 63d6b2abe5ad..70b7cfcc194f 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -16,6 +16,8 @@ output is split between common and driver specific parts. Having said that, wherever possible effort should still be made to standardise as much as possible. +.. contents:: + File format specification ========================= @@ -215,3 +217,4 @@ Driver specific implementations * :ref:`panfrost-usage-stats` * :ref:`panthor-usage-stats` * :ref:`xe-usage-stats` +* :ref:`amdxdna-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index eba09c3ddce4..0c9d68758533 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -1,3 +1,6 @@ + +.. _drm/i915: + =========================== drm/i915 Intel GFX Driver =========================== @@ -7,6 +10,9 @@ models) integrated GFX chipsets with both Intel display and rendering blocks. This excludes a set of SoC platforms with an SGX rendering unit, those have basic support through the gma500 drm driver. +The display, or :ref:`drm-kms`, support for drm/i915 is provided by +:ref:`drm/intel-display`, and shared with :ref:`drm/xe <drm/xe>`. + Core Driver Infrastructure ========================== @@ -64,200 +70,6 @@ Workarounds .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c :doc: Hardware workarounds -Display Hardware Handling -========================= - -This section covers everything related to the display hardware including -the mode setting infrastructure, plane, sprite and cursor handling and -display, output probing and related topics. - -Mode Setting Infrastructure ---------------------------- - -The i915 driver is thus far the only DRM driver which doesn't use the -common DRM helper code to implement mode setting sequences. Thus it has -its own tailor-made infrastructure for executing a display configuration -change. - -Frontbuffer Tracking --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c - :doc: frontbuffer tracking - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c - :internal: - -Display FIFO Underrun Reporting -------------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c - :doc: fifo underrun handling - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c - :internal: - -Plane Configuration -------------------- - -This section covers plane configuration and composition with the primary -plane, sprites, cursors and overlays. This includes the infrastructure -to do atomic vsync'ed updates of all this state and also tightly coupled -topics like watermark setup and computation, framebuffer compression and -panel self refresh. - -Atomic Plane Helpers --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c - :doc: atomic plane helpers - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c - :internal: - -Asynchronous Page Flip ----------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c - :doc: asynchronous flip implementation - -Output Probing --------------- - -This section covers output probing and related infrastructure like the -hotplug interrupt storm detection and mitigation code. Note that the -i915 driver still uses most of the common DRM helper code for output -probing, so those sections fully apply. - -Hotplug -------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c - :doc: Hotplug - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c - :internal: - -High Definition Audio ---------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c - :doc: High Definition Audio over HDMI and Display Port - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c - :internal: - -.. kernel-doc:: include/drm/intel/i915_component.h - :internal: - -Intel HDMI LPE Audio Support ----------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c - :doc: LPE Audio integration for HDMI or DP playback - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c - :internal: - -Panel Self Refresh PSR (PSR/SRD) --------------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c - :doc: Panel Self Refresh (PSR/SRD) - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c - :internal: - -Frame Buffer Compression (FBC) ------------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c - :doc: Frame Buffer Compression (FBC) - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c - :internal: - -Display Refresh Rate Switching (DRRS) -------------------------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :doc: Display Refresh Rate Switching (DRRS) - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c - :internal: - -DPIO ----- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c - :doc: DPIO - -DMC Firmware Support --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c - :doc: 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) ----------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c - :doc: Video BIOS Table (VBT) - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c - :internal: - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_vbt_defs.h - :internal: - -Display clocks --------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c - :doc: CDCLK / RAWCLK - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c - :internal: - -Display PLLs ------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c - :doc: Display PLLs - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c - :internal: - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h - :internal: - -Display State Buffer --------------------- - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c - :doc: DSB - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c - :internal: - GT Programming ============== @@ -568,7 +380,7 @@ The HuC FW layout is the same as the GuC one, see `GuC Firmware Layout`_ DMC --- -See `DMC Firmware Support`_ +See :ref:`drm/intel-display/dmc`. Tracing ======= diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 2fafa1f35ef3..65bf3b26e4f4 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -3,12 +3,14 @@ GPU Driver Developer's Guide ============================ .. toctree:: + :maxdepth: 2 introduction drm-internals drm-mm drm-kms drm-kms-helpers + drm-ras drm-uapi drm-usage-stats driver-uapi diff --git a/Documentation/gpu/intel-display/async-flip.rst b/Documentation/gpu/intel-display/async-flip.rst new file mode 100644 index 000000000000..40f93e885bb7 --- /dev/null +++ b/Documentation/gpu/intel-display/async-flip.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Asynchronous Page Flip +====================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c + :doc: asynchronous flip implementation diff --git a/Documentation/gpu/intel-display/atomic.rst b/Documentation/gpu/intel-display/atomic.rst new file mode 100644 index 000000000000..43a473181e7a --- /dev/null +++ b/Documentation/gpu/intel-display/atomic.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Atomic Modeset Support +====================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c + :doc: atomic modeset support + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c + :internal: diff --git a/Documentation/gpu/intel-display/audio.rst b/Documentation/gpu/intel-display/audio.rst new file mode 100644 index 000000000000..eef95df75f8d --- /dev/null +++ b/Documentation/gpu/intel-display/audio.rst @@ -0,0 +1,23 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +High Definition Audio +===================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c + :doc: High Definition Audio over HDMI and Display Port + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c + :internal: + +.. kernel-doc:: include/drm/intel/i915_component.h + :internal: + +Intel HDMI LPE Audio Support +============================ + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c + :doc: LPE Audio integration for HDMI or DP playback + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lpe_audio.c + :internal: diff --git a/Documentation/gpu/intel-display/casf.rst b/Documentation/gpu/intel-display/casf.rst new file mode 100644 index 000000000000..406778ccd94c --- /dev/null +++ b/Documentation/gpu/intel-display/casf.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Content Adaptive Sharpness Filter (CASF) +======================================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_casf.c + :doc: Content Adaptive Sharpness Filter (CASF) diff --git a/Documentation/gpu/intel-display/cdclk.rst b/Documentation/gpu/intel-display/cdclk.rst new file mode 100644 index 000000000000..a66d623b0ec9 --- /dev/null +++ b/Documentation/gpu/intel-display/cdclk.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display clocks +============== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c + :doc: CDCLK / RAWCLK + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cdclk.c + :internal: diff --git a/Documentation/gpu/intel-display/cmtg.rst b/Documentation/gpu/intel-display/cmtg.rst new file mode 100644 index 000000000000..04edd0bd165d --- /dev/null +++ b/Documentation/gpu/intel-display/cmtg.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Common Primary Timing Generator (CMTG) +====================================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_cmtg.c + :doc: Common Primary Timing Generator (CMTG) diff --git a/Documentation/gpu/intel-display/dmc.rst b/Documentation/gpu/intel-display/dmc.rst new file mode 100644 index 000000000000..4368da4c7048 --- /dev/null +++ b/Documentation/gpu/intel-display/dmc.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +.. _drm/intel-display/dmc: + +DMC Firmware Support +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c + :doc: 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 diff --git a/Documentation/gpu/intel-display/dp-link-capabilities.rst b/Documentation/gpu/intel-display/dp-link-capabilities.rst new file mode 100644 index 000000000000..331cc69d13a0 --- /dev/null +++ b/Documentation/gpu/intel-display/dp-link-capabilities.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +DisplayPort Link Capabilities +============================= + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp_link_caps.c + :doc: DisplayPort link capabilities + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp_link_caps.h + :internal: diff --git a/Documentation/gpu/intel-display/dp-link-training.rst b/Documentation/gpu/intel-display/dp-link-training.rst new file mode 100644 index 000000000000..d0bde965021d --- /dev/null +++ b/Documentation/gpu/intel-display/dp-link-training.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +DisplayPort Link Training +========================= + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp_link_training.c + :doc: DisplayPort link training diff --git a/Documentation/gpu/intel-display/dpio.rst b/Documentation/gpu/intel-display/dpio.rst new file mode 100644 index 000000000000..84d92ac162f8 --- /dev/null +++ b/Documentation/gpu/intel-display/dpio.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +DPIO +==== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c + :doc: DPIO diff --git a/Documentation/gpu/intel-display/dpll.rst b/Documentation/gpu/intel-display/dpll.rst new file mode 100644 index 000000000000..c750352e0ae5 --- /dev/null +++ b/Documentation/gpu/intel-display/dpll.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display PLLs +============ + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c + :doc: Display PLLs + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll_mgr.h + :internal: diff --git a/Documentation/gpu/intel-display/drrs.rst b/Documentation/gpu/intel-display/drrs.rst new file mode 100644 index 000000000000..a5aaba63d6b9 --- /dev/null +++ b/Documentation/gpu/intel-display/drrs.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display Refresh Rate Switching (DRRS) +===================================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :doc: Display Refresh Rate Switching (DRRS) + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :internal: diff --git a/Documentation/gpu/intel-display/dsb.rst b/Documentation/gpu/intel-display/dsb.rst new file mode 100644 index 000000000000..857aca59995a --- /dev/null +++ b/Documentation/gpu/intel-display/dsb.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display State Buffer +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c + :doc: DSB + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c + :internal: diff --git a/Documentation/gpu/intel-display/fbc.rst b/Documentation/gpu/intel-display/fbc.rst new file mode 100644 index 000000000000..de9e19021f50 --- /dev/null +++ b/Documentation/gpu/intel-display/fbc.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Frame Buffer Compression (FBC) +============================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c + :doc: Frame Buffer Compression (FBC) + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fbc.c + :internal: diff --git a/Documentation/gpu/intel-display/fifo-underrun.rst b/Documentation/gpu/intel-display/fifo-underrun.rst new file mode 100644 index 000000000000..5d8f01921506 --- /dev/null +++ b/Documentation/gpu/intel-display/fifo-underrun.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Display FIFO Underrun Reporting +=============================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c + :doc: fifo underrun handling + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c + :internal: diff --git a/Documentation/gpu/intel-display/frontbuffer.rst b/Documentation/gpu/intel-display/frontbuffer.rst new file mode 100644 index 000000000000..7ae38e0827bf --- /dev/null +++ b/Documentation/gpu/intel-display/frontbuffer.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Frontbuffer Tracking +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c + :doc: frontbuffer tracking + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_frontbuffer.c + :internal: diff --git a/Documentation/gpu/intel-display/hotplug.rst b/Documentation/gpu/intel-display/hotplug.rst new file mode 100644 index 000000000000..f33bc0087c27 --- /dev/null +++ b/Documentation/gpu/intel-display/hotplug.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Hotplug +======= + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c + :doc: Hotplug + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_hotplug.c + :internal: diff --git a/Documentation/gpu/intel-display/index.rst b/Documentation/gpu/intel-display/index.rst new file mode 100644 index 000000000000..e81f49bf20df --- /dev/null +++ b/Documentation/gpu/intel-display/index.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +.. _drm/intel-display: + +==================== +Intel Display Driver +==================== + +The Intel display driver provides the display, or :ref:`drm-kms`, support for +both the :ref:`drm/xe <drm/xe>` and :ref:`drm/i915 <drm/i915>` Intel GPU +drivers. + +The source code currently resides under ``drivers/gpu/drm/i915/display`` due to +historical reasons, and it's compiled separately into both drm/xe and drm/i915 +kernel modules. + +The drm/xe and drm/i915 drivers are the "core" or "parent" drivers for display, +as they initialize and own the drm device, and pass that on to the display +driver. The display driver isn't an independent driver in that sense. + +.. toctree:: + :maxdepth: 1 + :caption: Detailed display topics + + async-flip + atomic + audio + casf + cdclk + cmtg + dmc + dpio + dpll + drrs + dsb + fbc + fifo-underrun + frontbuffer + hotplug + dp-link-training + dp-link-capabilities + plane + psr + snps-phy + vbt diff --git a/Documentation/gpu/intel-display/plane.rst b/Documentation/gpu/intel-display/plane.rst new file mode 100644 index 000000000000..59932a82051b --- /dev/null +++ b/Documentation/gpu/intel-display/plane.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Atomic Plane Helpers +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c + :doc: atomic plane helpers + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c + :internal: diff --git a/Documentation/gpu/intel-display/psr.rst b/Documentation/gpu/intel-display/psr.rst new file mode 100644 index 000000000000..63e56abcdd56 --- /dev/null +++ b/Documentation/gpu/intel-display/psr.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Panel Self Refresh PSR (PSR/SRD) +================================ + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c + :doc: Panel Self Refresh (PSR/SRD) + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_psr.c + :internal: diff --git a/Documentation/gpu/intel-display/snps-phy.rst b/Documentation/gpu/intel-display/snps-phy.rst new file mode 100644 index 000000000000..c9e333fa7f62 --- /dev/null +++ b/Documentation/gpu/intel-display/snps-phy.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Synopsis PHY support +==================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_snps_phy.c + :doc: Synopsis PHY support diff --git a/Documentation/gpu/intel-display/vbt.rst b/Documentation/gpu/intel-display/vbt.rst new file mode 100644 index 000000000000..be69f7fd7b39 --- /dev/null +++ b/Documentation/gpu/intel-display/vbt.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: MIT +.. Copyright © 2026 Intel Corporation + +Video BIOS Table (VBT) +====================== + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c + :doc: Video BIOS Table (VBT) + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_bios.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_vbt_defs.h + :internal: diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 3cd0c8860b94..64074ac22d9b 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -16,6 +16,8 @@ found in current kernels. [Insert diagram of typical DRM stack here] +.. contents:: + Style Guidelines ================ @@ -119,12 +121,6 @@ Simple DRM drivers to use as examples The DRM subsystem contains a lot of helper functions to ease writing drivers for simple graphic devices. For example, the `drivers/gpu/drm/tiny/` directory has a set of drivers that are simple enough to be implemented in a single source file. - -These drivers make use of the `struct drm_simple_display_pipe_funcs`, that hides -any complexity of the DRM subsystem and just requires drivers to implement a few -functions needed to operate the device. This could be used for devices that just -need a display pipeline with one full-screen scanout buffer feeding one output. - The tiny DRM drivers are good examples to understand how DRM drivers should look like. Since are just a few hundreds lines of code, they are quite easy to read. diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst index eaea40eb725b..9c0745940659 100644 --- a/Documentation/gpu/komeda-kms.rst +++ b/Documentation/gpu/komeda-kms.rst @@ -367,7 +367,7 @@ So, one KMS-Obj represents a sub-pipeline of komeda resources. So, for komeda, we treat KMS crtc/plane/connector as users of pipeline and component, and at any one time a pipeline/component only can be used by one user. And pipeline/component will be treated as private object of DRM-KMS; the -state will be managed by drm_atomic_state as well. +state will be managed by drm_atomic_commit as well. How to map plane to Layer(input) pipeline ----------------------------------------- @@ -416,8 +416,8 @@ Add :c:type:`drm_private_obj` to :c:type:`komeda_component`, :c:type:`komeda_pip ... } -Tracking component_state/pipeline_state by drm_atomic_state ------------------------------------------------------------ +Tracking component_state/pipeline_state by drm_atomic_commit +------------------------------------------------------------ Add :c:type:`drm_private_state` and user to :c:type:`komeda_component_state`, :c:type:`komeda_pipeline_state` @@ -454,7 +454,7 @@ similar, usually including the following steps: put the data flow into next stage. Setup 2: check user_state with component features and capabilities to see if requirements can be met; if not, return fail. - Setup 3: get component_state from drm_atomic_state, and try set to set + Setup 3: get component_state from drm_atomic_commit, and try set to set user to component; fail if component has been assigned to another user already. Setup 3: configure the component_state, like set its input component, diff --git a/Documentation/gpu/nova/core/fsp.rst b/Documentation/gpu/nova/core/fsp.rst new file mode 100644 index 000000000000..52d618d22bb8 --- /dev/null +++ b/Documentation/gpu/nova/core/fsp.rst @@ -0,0 +1,142 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================================== +FSP (Foundation Security Processor) and Secure Boot +=================================================== +This document describes the role of the FSP in the GPU boot sequence on +Hopper and Blackwell GPUs, and how it differs from the earlier Ampere boot +flow. It also provides a brief overview of the PRC (Product Reconfiguration +Control) protocol used to query device configuration through FSP. As with +other documents in this directory, the information is subject to change and +is intended to help developers understand the corresponding kernel code. + +What is FSP? +============ +The Foundation Security Processor (FSP) is the GPU's Internal Root of Trust +(IROT). It is a dedicated security processor that boots from immutable ROM +(Boot ROM) inside the GPU and is responsible for establishing the Chain of +Trust before any other firmware is allowed to run. + +FSP runs independently of the host CPU and starts executing as soon as the +GPU is powered on. By the time the nova-core driver is loaded, FSP has +already completed its own secure boot and is ready to accept commands from +the driver. + +Simplified boot flow (Hopper/Blackwell) +======================================= +Starting with Hopper, the boot flow is significantly simplified compared to +earlier GPU generations like Ampere. + +On an **Ampere** GPU, the boot verification chain involves multiple Falcon +engines and multiple ucode stages (see falcon.rst for details):: + + Hardware BROM (SEC2) + -> HS Booter (SEC2) + -> LS GSP-RM (GSP) + +The driver must extract ucode from VBIOS, manage SEC2 and GSP, and +orchestrate the Booter to load GSP-RM. This involves FWSEC-FRTS, devinit, +and the Booter stages. + +On **Hopper/Blackwell** GPUs, FSP replaces this multi-stage process with a +single message-driven interface:: + + FSP (hardware root of trust, boots from ROM) + -> FMC (Falcon Microcontroller, verified by FSP) + -> GSP-RM (verified and loaded by FMC) + +The driver only needs to: + +1. Wait for FSP to complete its own secure boot (polling a scratch register). +2. Send a Chain of Trust (COT) message to FSP with the FMC firmware location, + cryptographic signatures, and GSP boot parameters. +3. FSP authenticates the FMC firmware and boots it, FMC in turn loads GSP-RM. + +There is no SEC2 involvement, no Booter ucode, and no FWSEC-FRTS stage. The +entire secure boot is driven by a single FSP message exchange. + +Chain of Trust (COT) protocol +============================= +The Chain of Trust establishes a cryptographically enforced boot sequence, +ensuring the GPU reaches a known, trusted state. + +The driver communicates with FSP using a message queue (Falcon MSGQ +interface). Each message consists of an MCTP (Management Component Transport +Protocol) transport header and an NVDM (NVIDIA Vendor Defined Message) header, +followed by a protocol-specific payload. + +For Chain of Trust, the payload includes: + +- The system memory address of the FMC firmware image. +- Cryptographic material: a SHA-384 hash, RSA-3K public key, and RSA-3K + signature extracted from the FMC ELF firmware. +- FRTS (Firmware Runtime Services) region information (vidmem offset and size). +- The system memory address of the GSP boot arguments structure. + +FSP verifies the signature against the provided public key and hash, and if +verification succeeds, boots the FMC. The FMC then authenticates and launches +GSP-RM. + +The message flow is:: + + nova-core FSP + | | + | 1. Poll scratch register | + | (wait for FSP boot complete) | + | | + | 2. COT message ------------> | + | (FMC addr, signatures, | + | boot params) | + | | + | |--- Verify FMC signature + | |--- Boot FMC + | |--- FMC loads GSP-RM + | | + | 3. COT response <------------ | + | (success/error) | + | | + +FSP message format +================== +All FSP messages share a common header format consisting of two 32-bit words: + +**MCTP header** (Management Component Transport Protocol): + +- Bit 31: SOM (Start of Message) +- Bit 30: EOM (End of Message) +- Bits 29:28: Packet sequence number +- Bits 23:16: Source Endpoint ID + +**NVDM header** (NVIDIA Vendor Defined Message): + +- Bits 6:0: MCTP message type (0x7e = vendor-defined PCI) +- Bits 23:8: PCI vendor ID (0x10de = NVIDIA) +- Bits 31:24: NVDM type (0x14 = COT, 0x13 = PRC, 0x15 = FSP response) + +PRC (Product Reconfiguration Control) protocol +=============================================== +PRC is an API system exposed through FSP's Management Partition that allows +querying and modifying device configuration without firmware updates. + +Configuration parameters are called "knobs". Each knob has a unique object +ID and controls a specific device behavior. Examples include vGPU mode, ECC +enable, confidential computing mode, and NVLINK configuration. + +Each knob has two values: + +- **Active**: the currently effective value for this boot cycle. +- **Persistent**: the value stored in InfoROM, applied on subsequent boots. + +The nova-core driver uses PRC to read the vGPU mode knob (object ID 0x29) +during early boot, before firmware loading, to determine whether the GPU +should operate in vGPU mode. + +The PRC message format follows the same MCTP/NVDM header structure as COT, +with NVDM type 0x13. The payload contains: + +- A sub-command (e.g., 0x0c for read). +- Flags indicating which value to read (bit 0 = persistent, bit 1 = active). +- The knob object ID. + +The response includes the common FSP response header (with error status) +followed by the knob's 16-bit state value. diff --git a/Documentation/gpu/nova/core/tlv.rst b/Documentation/gpu/nova/core/tlv.rst new file mode 100644 index 000000000000..3ce508e9545a --- /dev/null +++ b/Documentation/gpu/nova/core/tlv.rst @@ -0,0 +1,184 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +================================== +TLV Tags in Nova Firmware Images +================================== + +Nova firmware images use a Type-Length-Value (TLV) format to encapsulate +firmware components and metadata. The TLV file begins with a 4-byte "magic" +header that contains the string "NVFW". Following the header is a sequence of +TLV blocks. + +Each block consists of a 4-byte tag of ASCII characters, a 4-byte length +encoded as a little-endian unsigned integer, and a sequence of bytes, the size +of which is equal to the length rounded up to the next multiple of 4. + +The driver code that reads the TLV and uses its contents is called the parser. +It is the responsibility of the parser to handle missing or malformed tags, +lengths, and values in the TLV. + +:: + + +------+------+------+------+ + | 'N' | 'V' | 'F' | 'W' | Magic header + +------+------+------+------+ + | Tag (4 bytes, ASCII) | TLV block 0 + +---------------------------+ + | Length (4 bytes, LE) | + +---------------------------+ + | | + | Value (length bytes, | + | padded to 4-byte align) | + | | + +---------------------------+ + | Tag (4 bytes, ASCII) | TLV block 1 + +---------------------------+ + | Length (4 bytes, LE) | + +---------------------------+ + | | + | Value (length bytes, | + | padded to 4-byte align) | + | | + +---------------------------+ + | ... | More TLV blocks + +---------------------------+ + +Tags and Length +=============== +TLV tags are always four-character words, with all letters being upper case. +Duplicate tags are not allowed. + +A TLV file may contain additional tags not described in this document. + +Values +====== +Values are one of four types. The type is not encoded in the format; rather, +the parser expects a given tag to have a value of a given type. + +1) Integers, encoded in 32-bit or 64-bit little-endian format. +2) Strings, encoded as-is and required to be only printable ASCII characters + and without a null terminator. +3) An array of bytes, for binary data. +4) Boolean, encoded as single byte, with a value of 0 for False or 1 for True. + +Common Tags +=========== +These tags are shared across firmware types and carry the same meaning +wherever they appear. Unlike the firmware-specific tags below, a common tag +is reserved: its meaning is fixed and may never be redefined for a particular +firmware type. + +``VERS`` (string) + Human-readable firmware version string. Present in all TLV files. + +A TLV image must contain either a single ``BLOB`` tag (firmware embedded +inline) or a ``SIZE``/``FILE`` pair (firmware stored in a separate file). + +``BLOB`` (bytes) + If the firmware microcode binary is stored in the TLV, this tag contains + the actual firmware image bytes. + +``FILE`` (string) + If the firmware binary is stored as a separate file, this tag contains the + name of that file, which is required to be in the same directory as the TLV, + so no paths are allowed in the filename. This tag is always paired with + ``SIZE``, so as to allow the driver to pre-allocate the buffer before + loading the file. + +``SIZE`` (u32) + Total size in bytes of the firmware image to be loaded from the companion + file named by ``FILE``. This tag is mandatory if ``FILE`` exists, so the + size of the firmware image must be known when the TLV is created. If the + firmware image is updated and its size changes, then the TLV must be + updated with it. + +GSP Firmware Tags +================= +``SIGN`` (bytes) + Cryptographic signature for the GSP firmware. + +``BLID`` (string) + The build ID, extracted from the ".note.gnu.build-id" section. + +Booter Firmware Tags +==================== +``DAOF`` (u32) - ``os_data_offset`` + OS data section offset within the firmware image (absolute byte offset). + Maps to the DMEM load source. + +``DASZ`` (u32) - ``os_data_size`` + OS data section size in bytes. + +``CDOF`` (u32) - ``os_code_offset`` + OS code section offset within the firmware image (absolute byte offset). + Maps to the non-secure IMEM load source. + +``CDSZ`` (u32) - ``os_code_size`` + OS code section size in bytes. + +``PLOC`` (u32) - ``patch_loc`` + Signature patch location -- byte offset within the firmware image where the + selected signature should be written. + +``FUSE`` (u32) - ``fuse_version`` + Fuse version of the firmware, used with the hardware fuse register to + select the correct signature index. + +``ENID`` (u32) - ``engine_id`` + Engine ID mask identifying the falcon engine this firmware targets. + +``UCID`` (u32) - ``ucode_id`` + Microcode ID used together with the engine ID to query hardware signature + fuse registers. + +``A0CO`` (u32) - ``app0_code_offset`` + App0 code offset -- start of the secure code region within the firmware + image. Used as the IMEM secure section source. + +``A0CS`` (u32) - ``app0_code_size`` + App0 code size in bytes. + +``NSIG`` (u32) - ``num_sigs`` + Number of signatures included in the ``SIGN`` tag. + +``SIGN`` (bytes) + Concatenated array of firmware signatures. The size of each signature is + the total length of the ``SIGN`` value divided by ``NSIG``. The correct + signature is selected using the fuse-version-derived index. + +Generic Bootloader Tags +======================= +``CDSZ`` (u32) - ``code_size`` + Size in bytes of the bootloader code to copy from the ``BLOB`` tag and + PIO-load into falcon IMEM. + +``STRT`` (u32) - ``start_tag`` + Start tag identifying the IMEM block where execution begins. The falcon + boot address is derived as ``start_tag << 8``. + +GSP Bootloader Tags +=================== +``CDOF`` (u32) - ``code_offset`` + Offset within the firmware image at which the code section starts. + +``DAOF`` (u32) - ``data_offset`` + Offset within the firmware image at which the data section starts. + +``MFOF`` (u32) - ``manifest_offset`` + Offset within the firmware image at which the manifest starts. + +``APPV`` (u32) - ``app_version`` + Application version of the firmware. + +FMC Firmware Tags +================= +``HASH`` (bytes) + SHA-384 hash of the FMC firmware, exactly 48 bytes long. + +``PKEY`` (bytes) + Public key used to verify the FMC firmware. At most 384 bytes (RSA-3072), + but may be shorter. + +``SIGN`` (bytes) + Signature of the FMC firmware. At most 384 bytes (RSA-3072), but may + be shorter. diff --git a/Documentation/gpu/nova/core/todo.rst b/Documentation/gpu/nova/core/todo.rst index d1964eb645e2..d5130b2b08fb 100644 --- a/Documentation/gpu/nova/core/todo.rst +++ b/Documentation/gpu/nova/core/todo.rst @@ -51,82 +51,6 @@ There also have been considerations of ToPrimitive [2]. | Link: https://lore.kernel.org/all/cover.1750689857.git.y.j3ms.n@gmail.com/ [1] | Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Implement.20.60FromPrimitive.60.20trait.20.2B.20derive.20macro.20for.20nova-core/with/541971854 [2] -Generic register abstraction [REGA] ------------------------------------ - -Work out how register constants and structures can be automatically generated -through generalized macros. - -Example: - -.. code-block:: rust - - register!(BOOT0, 0x0, u32, pci::Bar<SIZE>, Fields [ - MINOR_REVISION(3:0, RO), - MAJOR_REVISION(7:4, RO), - REVISION(7:0, RO), // Virtual register combining major and minor rev. - ]) - -This could expand to something like: - -.. code-block:: rust - - const BOOT0_OFFSET: usize = 0x00000000; - const BOOT0_MINOR_REVISION_SHIFT: u8 = 0; - const BOOT0_MINOR_REVISION_MASK: u32 = 0x0000000f; - const BOOT0_MAJOR_REVISION_SHIFT: u8 = 4; - const BOOT0_MAJOR_REVISION_MASK: u32 = 0x000000f0; - const BOOT0_REVISION_SHIFT: u8 = BOOT0_MINOR_REVISION_SHIFT; - const BOOT0_REVISION_MASK: u32 = BOOT0_MINOR_REVISION_MASK | BOOT0_MAJOR_REVISION_MASK; - - struct Boot0(u32); - - impl Boot0 { - #[inline] - fn read(bar: &RevocableGuard<'_, pci::Bar<SIZE>>) -> Self { - Self(bar.readl(BOOT0_OFFSET)) - } - - #[inline] - fn minor_revision(&self) -> u32 { - (self.0 & BOOT0_MINOR_REVISION_MASK) >> BOOT0_MINOR_REVISION_SHIFT - } - - #[inline] - fn major_revision(&self) -> u32 { - (self.0 & BOOT0_MAJOR_REVISION_MASK) >> BOOT0_MAJOR_REVISION_SHIFT - } - - #[inline] - fn revision(&self) -> u32 { - (self.0 & BOOT0_REVISION_MASK) >> BOOT0_REVISION_SHIFT - } - } - -Usage: - -.. code-block:: rust - - let bar = bar.try_access().ok_or(ENXIO)?; - - let boot0 = Boot0::read(&bar); - pr_info!("Revision: {}\n", boot0.revision()); - -A work-in-progress implementation currently resides in -`drivers/gpu/nova-core/regs/macros.rs` and is used in nova-core. It would be -nice to improve it (possibly using proc macros) and move it to the `kernel` -crate so it can be used by other components as well. - -Features desired before this happens: - -* Make I/O optional I/O (for field values that are not registers), -* Support other sizes than `u32`, -* Allow visibility control for registers and individual fields, -* Use Rust slice syntax to express fields ranges. - -| Complexity: Advanced -| Contact: Alexandre Courbot - Numerical operations [NUMM] --------------------------- diff --git a/Documentation/gpu/nova/core/vbios.rst b/Documentation/gpu/nova/core/vbios.rst index efd40087480c..9d3379ccfb30 100644 --- a/Documentation/gpu/nova/core/vbios.rst +++ b/Documentation/gpu/nova/core/vbios.rst @@ -46,12 +46,71 @@ region is only accessible to heavy-secure ucode. are of type 0xE0 and can be identified as such. This could be subject to change in future generations. +IFR Header +---------- +On Kepler and later GPUs, the ROM begins with an Init-from-ROM (IFR) header +rather than a standard PCI ROM signature (0xAA55). The driver must parse the +IFR header to find where the PCI ROM images actually start. + +Init-from-ROM (IFR) is a special GPU feature used for power management +on some Nvidia GPUs. It references data in the VBIOS for its operation, +but for drivers the important piece is a header that precedes the +VBIOS PCI Expansion ROM. + +Most such GPUs do not need to parse the IFR header in order to find the +VBIOS, but the Nvidia GA100 is the exception. GA100 lacks a display engine, +so the PRAMIN method (which reads the VBIOS from VRAM via display hardware) +is unavailable, forcing the driver to read the ROM directly via PROM. +On other similar GPUs, either PRAMIN succeeds before PROM is tried, or the +IFR hardware has already applied the ROM offset so that PROM reads +transparently skip the IFR header. + +The driver should first check for the standard 0xAA55 signature at offset 0. +If found, there is no IFR header and the PCI ROM images start at +offset 0. If not found, check for the IFR signature and parse the header to +determine the PCI ROM image offset. + +Fixed Header Format +~~~~~~~~~~~~~~~~~~~ + +The IFR header begins with four 32-bit words at fixed offsets:: + + Offset Name Fields + ------ ------- ------ + 0x00 FIXED0 bits 31:0 - Signature (must be 0x4947564E, ASCII "NVGI") + 0x04 FIXED1 bit 31 - Reserved + bits 30:16 - FIXED_DATA_SIZE Fixed data size (offset to extended section) + bits 15:8 - VERSIONSW Software version + bits 7:0 - Reserved + 0x08 FIXED2 bit 31 - Reserved + bits 30:20 - Reserved (zero) + bits 19:0 - TOTAL_DATA_SIZE Total data size + +Finding the PCI ROM Image Offset +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The method to find this offset depends on `VERSIONSW`. + +- **Version 1 and 2**: Read `FIXED_DATA_SIZE` from `FIXED1` to get the extended + section offset. The PCI ROM image is the 32-bit value at `FIXED_DATA_SIZE + 4`. + +- **Version 3**: Read `TOTAL_DATA_SIZE` from `FIXED2`. The 32-bit value at that + offset is a flash status offset. Add 4096 to get the ROM directory offset, + `ROM_DIRECTORY_OFFSET`. The ROM directory must have signature 0x44524652 + (ASCII "RFRD"). The PCI ROM image offset is the 32-bit value at + `ROM_DIRECTORY_OFFSET + 8`. + +The PCI ROM image offset must be 4-byte aligned. All offsets are relative to the +start of ROM (BAR0 + 0x300000). + VBIOS ROM Layout ---------------- -The VBIOS layout is roughly a series of concatenated images laid out as follows:: +The VBIOS (PCI Expansion ROM) is a series of concatenated images laid out as +follows. On GPUs with an IFR header, this layout begins at the image offset +determined by parsing the IFR header. On older GPUs, it begins at offset 0:: +----------------------------------------------------------------------------+ - | VBIOS (Starting at ROM_OFFSET: 0x300000) | + | VBIOS (Starting at ROM_OFFSET: 0x300000 + IFR image offset) | +----------------------------------------------------------------------------+ | +-----------------------------------------------+ | | | PciAt Image (Type 0x00) | | @@ -173,7 +232,7 @@ Falcon data in the VBIOS which contains the PMU lookup table. This lookup table used to find the required Falcon ucode based on an application ID. The location of the PMU lookup table is found by scanning the BIT (`BIOS Information Table`_) -tokens for a token with the id `BIT_TOKEN_ID_FALCON_DATA` (0x70) which indicates the +tokens for a token with the Falcon data token id (0x70) which indicates the offset of the same from the start of the VBIOS image. Unfortunately, the offset does not account for the EFI image located between the PciAt and FwSec images. The `vbios.rs` code compensates for this with appropriate arithmetic. diff --git a/Documentation/gpu/nova/index.rst b/Documentation/gpu/nova/index.rst index e39cb3163581..2afa58e8f08d 100644 --- a/Documentation/gpu/nova/index.rst +++ b/Documentation/gpu/nova/index.rst @@ -30,5 +30,7 @@ vGPU manager VFIO driver and the nova-drm driver. core/todo core/vbios core/devinit + core/fsp core/fwsec core/falcon + core/tlv diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index ef19b0ba2a3e..26a7ebe6fb44 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -18,23 +18,9 @@ host such documentation: .. toctree:: - gpusvm.rst - -.. toctree:: - - i915_gem_lmem.rst - -.. toctree:: - - i915_scheduler.rst - -.. toctree:: - - i915_small_bar.rst - -.. toctree:: - - i915_vm_bind.rst - -.. toctree:: - color_pipeline.rst
\ No newline at end of file + gpusvm + i915_gem_lmem + i915_scheduler + i915_small_bar + i915_vm_bind + color_pipeline diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 520da44a04a6..14cf37590fc7 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -29,6 +29,38 @@ refactorings already and are an expert in the specific area Subsystem-wide refactorings =========================== +Open-code drm_simple_encoder_init() +----------------------------------- + +The helper drm_simple_encoder_init() was supposed to simplify encoder +initialization. Instead it only added an intermediate layer between atomic +modesetting and the DRM driver. + +The task here is to remove drm_simple_encoder_init(). Search for a driver +that calls drm_simple_encoder_init() and inline the helper. The driver will +also need its own instance of drm_encoder_funcs. + +Contact: Thomas Zimmermann, respective driver maintainer + +Level: Easy + +Replace struct drm_simple_display_pipe with regular atomic helpers +------------------------------------------------------------------ + +The data type struct drm_simple_display_pipe and its helpers were supposed +to simplify driver development. Instead they only added an intermediate layer +between atomic modesetting and the DRM driver. + +There are still drivers that use drm_simple_display_pipe. The task here is to +convert them to use regular atomic helpers. Search for a driver that calls +drm_simple_display_pipe_init() and inline all helpers from drm_simple_kms_helper.c +into the driver, such that no simple-KMS interfaces are required. Please also +rename all inlined functions according to driver conventions. + +Contact: Thomas Zimmermann, respective driver maintainer + +Level: Easy + Remove custom dumb_map_offset implementations --------------------------------------------- @@ -120,29 +152,6 @@ Contact: Simona Vetter, respective driver maintainers Level: Advanced -Rename drm_atomic_state ------------------------ - -The KMS framework uses two slightly different definitions for the ``state`` -concept. For a given object (plane, CRTC, encoder, etc., so -``drm_$OBJECT_state``), the state is the entire state of that object. However, -at the device level, ``drm_atomic_state`` refers to a state update for a -limited number of objects. - -The state isn't the entire device state, but only the full state of some -objects in that device. This is confusing to newcomers, and -``drm_atomic_state`` should be renamed to something clearer like -``drm_atomic_commit``. - -In addition to renaming the structure itself, it would also imply renaming some -related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``, -``drm_atomic_state_put``, ``drm_atomic_state_init``, -``__drm_atomic_state_free``, etc.). - -Contact: Maxime Ripard <mripard@kernel.org> - -Level: Advanced - Fallout from atomic KMS ----------------------- @@ -887,10 +896,11 @@ complection of submission. One minor feature still missing is a generic DRM IOCTL to query the error status of binary and timeline drm_syncobj. -This should probably be improved by implementing the necessary kernel interface -and adding support for that in the userspace stack. +This was already improved by implementing the necessary kernel interface +(patches are on the dri-devel mailing list) but adding support for that in the +userspace stack is still missing. -Contact: Christian König +Contact: Christian König, Michel Dänzer Level: Starter @@ -939,6 +949,47 @@ Contact: Philipp Stanner <phasta@kernel.org> Level: Intermediate +Replace the lockless queue with a locked list +--------------------------------------------- + +drm_sched is the only user in the entire kernel of a special lockless queue, the +spsc_queue. This queue utilizes: + +- preempt_disable() +- atomic instructions +- memory barriers +- ACCESS_ONCE() + +whereas a conventional spinlock utilizes: + +- preempt_disable() +- 1 atomic instruction for taking / releasing the lock +- memory barriers + +Moreover, drm_sched_entity_push_job(), the only user of spsc_queue_push(), has +to take a lock in some situations anyways and calls to it are often serialized +with a driver lock. + +It is, thus, highly questionable whether the lockless queue grants any advantage +at all. Considering that its internals are not well documented and its correctness +is not formally proven, it seems desirable to replace the queue with a mere list +or hlist that is protected by a spinlock. + +Tasks: + +- Replace the spsc_queue in drm/sched (and those who might access the scheduler's + internal queue) with a spinlock + (h)list. +- Ideally, check with some micro benchmarks and real world tests (preferably + with amdgpu) for relevant performance regressions. +- Remove the spsc_queue from the kernel altogether. + +Contact: + +- Philipp Stanner <phasta@kernel.org> +- Christian König <christian.koenig@amd.com> + +Level: Beginner + Outside DRM =========== diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst index bc432c95d1a3..665c0e93601c 100644 --- a/Documentation/gpu/xe/index.rst +++ b/Documentation/gpu/xe/index.rst @@ -1,5 +1,7 @@ .. SPDX-License-Identifier: (GPL-2.0+ OR MIT) +.. _drm/xe: + ======================= drm/xe Intel GFX Driver ======================= @@ -8,6 +10,9 @@ The drm/xe driver supports some future GFX cards with rendering, display, compute and media. Support for currently available platforms like TGL, ADL, DG2, etc is provided to prototype the driver. +The display, or :ref:`drm-kms`, support for drm/xe is provided by +:ref:`drm/intel-display`, and shared with :ref:`drm/i915 <drm/i915>`. + .. toctree:: :titlesonly: @@ -29,3 +34,4 @@ DG2, etc is provided to prototype the driver. xe_device xe-drm-usage-stats.rst xe_configfs + xe_gt_stats diff --git a/Documentation/gpu/xe/xe_device.rst b/Documentation/gpu/xe/xe_device.rst index 39a937b97cd3..d3a022362ade 100644 --- a/Documentation/gpu/xe/xe_device.rst +++ b/Documentation/gpu/xe/xe_device.rst @@ -8,3 +8,10 @@ Xe Device Wedging .. kernel-doc:: drivers/gpu/drm/xe/xe_device.c :doc: Xe Device Wedging + +==================== +GPU Health Indicator +==================== + +.. kernel-doc:: drivers/gpu/drm/xe/xe_ras.c + :doc: GPU Health Indicator diff --git a/Documentation/gpu/xe/xe_firmware.rst b/Documentation/gpu/xe/xe_firmware.rst index 5d23e9f27391..d3030d1c9a84 100644 --- a/Documentation/gpu/xe/xe_firmware.rst +++ b/Documentation/gpu/xe/xe_firmware.rst @@ -7,10 +7,10 @@ Firmware Firmware Layout =============== -.. kernel-doc:: drivers/gpu/drm/xe/xe_uc_fw_abi.h +.. kernel-doc:: drivers/gpu/drm/xe/abi/uc_fw_abi.h :doc: CSS-based Firmware Layout -.. kernel-doc:: drivers/gpu/drm/xe/xe_uc_fw_abi.h +.. kernel-doc:: drivers/gpu/drm/xe/abi/uc_fw_abi.h :doc: GSC-based Firmware Layout Write Once Protected Content Memory (WOPCM) Layout @@ -31,6 +31,9 @@ GuC Power Conservation (PC) .. kernel-doc:: drivers/gpu/drm/xe/xe_guc_pc.c :doc: GuC Power Conservation (PC) +.. kernel-doc:: drivers/gpu/drm/xe/xe_guc_rc.c + :doc: GuC Render C-states (GuC RC) + PCIe Gen5 Limitations ===================== diff --git a/Documentation/gpu/xe/xe_gt_stats.rst b/Documentation/gpu/xe/xe_gt_stats.rst new file mode 100644 index 000000000000..5ff806abaddb --- /dev/null +++ b/Documentation/gpu/xe/xe_gt_stats.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +================ +Xe GT Statistics +================ + +.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_stats.c + :doc: Xe GT Statistics + +.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_stats_types.h + :internal: |