BRIDGE OPERATIONS(9)

📦 version 7.3.1, in nixpkgs unstable

💅 NAME

okay so bestie, this is bridge operations from the Kernel API Manual — section 9, kernel API girlboss territory 👑✨. It’s all about how bridge drivers expose their ops and how the DRM internals call them.

✨ DESCRIPTION

Bridge drivers expose operations through the drm_bridge_funcs structure — that’s the whole vibe. The DRM internals (atomic and CRTC helpers) use the helpers defined in drm_bridge.c to call bridge operations. Those operations are divided into three big categories to support different parts of bridge usage 💖.

  • The encoder-related operations support control of the bridges in the chain, and are roughly counterparts to the drm_encoder_helper_funcs operations. They’re used by the legacy CRTC and the atomic modeset helpers to perform mode validation, fixup and setting, and enable and disable the bridge automatically. iconic behavior fr.

and btw, the enable and disable operations are split into drm_bridge_funcs.atomic_pre_enable, drm_bridge_funcs.atomic_enable, drm_bridge_funcs.atomic_disable and drm_bridge_funcs.atomic_post_disable to provide finer-grained control 🎀.

Bridge drivers may implement the legacy version of those operations, or the atomic version (prefixed with atomic_), in which case they shall also implement the atomic state bookkeeping operations (drm_bridge_funcs.atomic_duplicate_state, drm_bridge_funcs.atomic_destroy_state and drm_bridge_funcs.reset).

🚫 Mixing atomic and non-atomic versions of the operations is not supported. periodt.
  • The bus format negotiation operations drm_bridge_funcs.atomic_get_output_bus_fmts and drm_bridge_funcs.atomic_get_input_bus_fmts allow bridge drivers to negotiate the formats transmitted between bridges in the chain when multiple formats are supported. Negotiation for formats is performed transparently for display drivers by the atomic modeset helpers. Only atomic versions of those operations exist, bridge drivers that need to implement them shall thus also implement the atomic version of the encoder-related operations.
🌈 This feature is not supported by the legacy CRTC helpers. no cap.
  • The connector-related operations support implementing a drm_connector based on a chain of bridges. DRM bridges traditionally create a drm_connector for bridges meant to be used at the end of the chain. This puts additional burden on bridge drivers, especially for bridges that may be used in the middle of a chain or at the end of it. Furthermore, it requires all operations of the drm_connector to be handled by a single bridge, which doesn’t always match the hardware architecture. it’s giving main-character bottleneck 😭.

To simplify bridge drivers and make the connector implementation more flexible, a new model allows bridges to unconditionally skip creation of drm_connector and instead expose drm_bridge_funcs operations to support an externally-implemented drm_connector. Those operations are drm_bridge_funcs.detect, drm_bridge_funcs.get_modes, drm_bridge_funcs.get_edid, drm_bridge_funcs.hpd_notify, drm_bridge_funcs.hpd_enable and drm_bridge_funcs.hpd_disable. When implemented, display drivers shall create a drm_connector instance for each chain of bridges, and implement those connector instances based on the bridge connector operations. slay 🫶.

Bridge drivers shall implement the connector-related operations for all the features that the bridge hardware support. For instance, if a bridge supports reading EDID, the drm_bridge_funcs.get_edid shall be implemented. This however doesn’t mean that the DDC lines are wired to the bridge on a particular platform, as they could also be connected to an I2C controller of the SoC. Support for the connector-related operations on the running platform is reported through the drm_bridge.ops flags. Bridge drivers shall detect which operations they can support on the platform (usually this information is provided by ACPI or DT), and set the drm_bridge.ops flags for all supported operations. A flag shall only be set if the corresponding drm_bridge_funcs operation is implemented, but an implemented operation doesn’t necessarily imply that the corresponding flag will be set. Display drivers shall use the drm_bridge.ops flags to decide which bridge to delegate a connector operation to. This mechanism allows providing a single static const drm_bridge_funcs instance in bridge drivers, improving security by storing function pointers in read-only memory. security slay 🔐✨.

In order to ease transition, bridge drivers may support both the old and new models by making connector creation optional and implementing the connected-related bridge operations. Connector creation is then controlled by the flags argument to the drm_bridge_attach function. Display drivers that support the new model and create connectors themselves shall set the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, and bridge drivers shall then skip connector creation. For intermediate bridges in the chain, the flag shall be passed to the drm_bridge_attach call for the downstream bridge. Bridge drivers that implement the new model only shall return an error from their drm_bridge_funcs.attach handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not set. New display drivers should use the new model, and convert the bridge drivers they use if needed, in order to gradually transition to the new model. glow-up arc fr fr 🦋.

🌈 SEE ALSO

mwah 💋 — source/version: ./drivers/gpu/drm, date: October 2026, manual: bridge operations(9).

📦 where this page comes from