Part 9: Mapping the KMS Model onto Intel Hardware

In the previous two articles, we took a deep dive into the GPU's "heart" (GT) and "blood" (GEM). Today, we turn to the GPU's "eyes"—the display subsystem. In the Linux kernel, display drivers follow the KMS (Kernel Mode Setting) model.

For the i915 driver, the challenge lies in how to precisely map KMS's generic abstractions (CRTC, Plane, Connector, Encoder) onto Intel's complex display hardware pipeline (Pipes, Transcoders, DDIs).

1. Mapping Software Abstractions to Hardware Entities

To understand the display flow, we must first establish a mapping table from "software objects" to "hardware circuits":

KMS Object (DRM)	i915 Implementation Struct	Corresponding Intel HW Block	Responsibility
Plane	intel_plane	Hardware Plane	Pixel layer, responsible for scaling, rotation, and format conversion.
CRTC	intel_crtc	Pipe	Scanline generator, responsible for blending layers and applying the color Look-Up Table (LUT).
(No direct equivalent)	(maintained in state)	Transcoder	Protocol converter, responsible for encoding Pipe signals into timing signals (e.g., HDMI/DP timing).
Encoder	intel_encoder	DDI / Port	Digital Display Interface, the physical output endpoint (e.g., Port A, Port B).
Connector	intel_connector	Physical Socket	Receives the panel's EDID, detects HPD (Hot Plug Detect).

2. The Core Hardware Pipeline: Pipes and Transcoders

In Intel's documentation, the display pipeline is typically described as a series of connected modules.

2.1 Pipe

The core of intel_crtc is the Pipe (typically named Pipe A, B, C, D).

• Task: It fetches the pixels of each Plane from memory, blends them according to Z-order, and applies Gamma correction and Color Space Conversion (CSC).
• Mapping: One intel_crtc instance strictly corresponds to one physical Pipe.

2.2 Transcoder

This is a concept easily confused. In modern Intel hardware, an abstraction layer called the Transcoder is added between the Pipe and the output port.

• Role: It determines the output timing. For example, even if you are using Pipe A, if you are driving an eDP panel, it might be routed to TRANSCODER_EDP; for a normal DP output, it might use TRANSCODER_A.
• Flexibility: This design allows the hardware to share display logic among different physical interfaces.

3. Flexible Output Endpoints: DDI and Port

Before the Sandy Bridge era, Intel hardware had dedicated HDMI controllers, DP controllers, etc. Starting with the Haswell architecture, Intel introduced the DDI (Digital Display Interface).

• Essence of DDI: It is a universal physical interface. Through programming, the same DDI port can run either HDMI or DisplayPort.
• Role of the Encoder: In i915, intel_encoder represents a DDI port. Due to the versatility of DDI, a single intel_encoder can often handle multiple protocols simultaneously.

4. A Pixel's Fantastic Journey: Data Flow Example

Imagine you are gaming on a laptop connected to an external 4K monitor:

1. Plane: The game frame, as an intel_plane, waits in video memory (LMEM/SMEM).
2. Pipe: The intel_crtc (Pipe A) blends the game frame layer with the mouse cursor layer (Cursor Plane).
3. Transcoder: TRANSCODER_A generates the blanking and synchronization signals for 4K@60Hz.
4. Encoder: The signal flows to the DDI port (Port B), where the pixels are packetized into DisplayPort Micro-packets.
5. Connector: Finally, through the physical Type-C/DP port, the pixels race to the monitor.

5. Glossary: A Guide to Avoiding Pitfalls

When reading the i915 source code, you will encounter the following high-frequency terms:

• FDI (Flexible Display Interface): The pathway connecting the CPU to the PCH display chip in older architectures (largely obsolete on modern GPUs but commonly found in legacy code).
• PCH (Platform Controller Hub): The motherboard southbridge, which previously handled some display outputs; now most of that logic is integrated into the CPU.
• Watermarks: This is an extremely complex topic. A Pipe needs time to read data from memory, and Watermarks determine when the hardware initiates memory requests to prevent the display buffer from "running dry" and causing screen flicker.

Summary

The i915 display driver essentially "pieces together" the generic KMS model onto Intel's specific hardware pipeline. intel_crtc controls the Pipe's blending logic, while intel_encoder manages the flexible DDI interface. The Transcoder in between serves as the link connecting the two.

In the next lecture, we will delve into the part that gives display driver engineers the biggest headache: the two-phase commit mechanism of Atomic Modesetting.