This talk is targeted at people who are going to work on DRM.

sched – no slides 🙁

The typical display hardware pipeline consists of framebuffer that is connected to a plane (doing scaling, rotation, pixelformat conversion, and mixing multiple planes). The mixed planes go to CRTC that generates the timings to serialize pixels to the output. The encoder reads out pixels at a fixed rate and encapsulates them according to the format (e.g. HDMI supports multiple formats). Possibly there is still a bridge that does transcoding, e.g. HDMI to DisplayPort. Finally there’s a connector into the panel (always connected) or monitor (pluggable).

The display controller can be over PCIe (graphics card) or embedded in the SoC. A bridge may also be embedded into the SoC or graphics card. There may be dedicated RAM for the graphics card, or shared memory. Shared memory may have an IOMMU; if not, buffers have to be allocated and reserved contiguously. Shared memory also requires cache management.

fbdev has a lot of issues, but some people are still using it. It’s also hard to replace for some use cases.

DRM/KMS drivers are registered from the bus: pic, platform. For bridges and panels they usually come through i2c or spi, but also mipi_dsi. Drivers register there various components: drm_device, drm_bridge, drm_panel. The connections between components are described as a graph in device tree or ACPI. In device tree it’s with port/endpoint nodes which refer to other endpoints. In the case of mipi_dsi, this is not needed because the panel is a direct child of the dsi node.

A DRM driver structure consists of a features bitfield, file operations for userspace access, various information, and callbacks for GEM memory managers. The drm_device structure is created by the DRM framework and is associated with uAPI character devices. In probe, the driver allocaes the drm_device with drm_dev_alloc or devm_drm_dev_alloc. A commandline option must be checked to see if modesetting is allowed. Then the components are allocated: drm_plan, drm_crtc, drm_encoder, drm_connector. They have to be connected to each other. In shutdown, the drm_atomic_helper_shutdown shuts down CRTCs cleanly. There are similar helpers for suspend/resume.

DRM has two memory managers, TTM and GEM. TTM is historic, it’s big and complex, but it’s the only one that supports dedicated video memory. GEM only supports shared memory. It provides the fops that can be used by a driver. There’s a callback to apply alignment constraints on allocation. Other than that GEM manages memory by itself. It supports both with and without IOMMU. Without IOMMU, you’ll typically need to use CMA (Contiguous Memory Allocator) with an early boot reservation (with kconfig option or commandline). It’s also possible to create a dedicated pool for a specific device, declared in device tree.

drm_mode_config is used to configure a memory allocation. The structure defines limits for dimensions and a preferred pixel depth, and callbacks for handling mode configuration.

The Atomic API allows userspace to configure the different parts of the pipeline and then apply it atomically. This is kept in drm_atomic_state structures for each component; they are first created and then committed. In both steps, the driver has access to both the old and the new state.

Planes have a type, a mask of the CRTCs they can be connected to, the supported pixel formats, and special modifiers e.g. tiling. There are a set of driver callback functions for manipulating planes, often helper functions can be used for most functionality.

drm_display_mode and drm_display_info contain information about the monitor or panel.

[Things became too hard to follow here.]

drm_bridge and drm_panel drivers are separate drivers from the drm component. Panels also have an attached backlight device. There is an abstraction that wraps the panel API under the bridge API, so that display controller drivers only need to handle bridges and they get everything with a single API. A panel contains an LCD controller, but it’s important to not identify a panel driver with that LCD controller because the same controller can be used in completely different panels.

Slides are available on https://bootlin.com/pub/conferences/