drm_atomic_a...oder_bridges(9)

📦 version 7.3.1, in nixpkgs unstable

💖 NAME 💖

drm_atomic_add_encoder_bridges — adds the bridges that are attached to an encoder, slay

So this is a page from the Kernel API Manual, bestie, and it's all about drm_atomic_add_encoder_bridges. It's giving "tiny function, big responsibilities" energy, ngl. 🎀

✨ SYNOPSIS ✨

int drm_atomic_add_encoder_bridges (struct drm_atomic_commit *state ,
struct drm_encoder *encoder );

Like, that's the whole signature. Two args. No cap. 🫶

🌸 ARGUMENTS 🌸

  • state — the atomic state. Yeah. That one. The main character of the whole atomic sequence, honestly. 👑
  • encoder — a DRM encoder. It's the thing whose bridges we're about to collect. 💅

🦋 DESCRIPTION 🦋

Okay so here's the tea: this function adds all the bridges attached to encoder. All of them. Every single one. Obsessed. ✨

Why do we even care? Because you need those bridge states sitting inside state so they're actually available when these get called:

  • drm_bridge_funcs.atomic_check
  • drm_bridge_funcs.atomic_pre_enable
  • drm_bridge_funcs.atomic_enable
  • drm_bridge_funcs.atomic_disable_post_disable

That's the whole reason, fr fr. No bridge states in state = those callbacks are gonna have a bad time. 💀

🔥 RETURN 🔥

  • 0 — success, we ate, periodt. 🎉
  • -EDEADLK — uh oh. 😭 The w/w mutex code has detected a deadlock and the entire atomic sequence must be restarted. Like, the entire sequence. Start over. Don't fight it.
  • -ENOMEM — also possible, because memory said no. 🙈
Heads up bestie: when the error is EDEADLK, that's the w/w mutex code flagging a deadlock and you genuinely have to restart the whole atomic sequence. All other errors are fatal. Like, no recovery arc. 💀

🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/drm/drm_atomic.c, plus all of these icons:

Okay that's the whole page, bestie 💜 This little gem lives in ./drivers/gpu/drm, dated October 2026 — go forth and add those bridges, ily, bye! 🧚✨

📦 where this page comes from