drm_atomic_b...post_disable(9)

📦 version 7.3.1, in nixpkgs unstable

✨ drm_atomic_bridge_chain_post_disable 💅

okay bestie, welcome to the Kernel API Manual, this one's drm_atomic_b...post_disable(9) and it's lowkey the cleanup crew of the bridge world 🧹✨

🌸 NAME 🌸

drm_atomic_bridge_chain_post_disable — cleans up after disabling all bridges in the encoder chain 🫶

🦋 SYNOPSIS 🦋

void drm_atomic_bridge_chain_post_disable (struct drm_bridge *bridge ,
struct drm_atomic_commit *state );

🎀 ARGUMENTS 🎀

  • bridge — the bridge control structure, main character energy fr
  • state — the atomic state being committed, iykyk

💖 DESCRIPTION 💖

so the way this works 😭 — it calls the drm_bridge_funcs.atomic_post_disable op for all the bridges in the encoder chain, starting from the first bridge to the last. literally every single one, no skips, no cap.

these get called after completing drm_encoder_helper_funcs.atomic_disable ⭐

and here's the little plot twist 🌀 — if a bridge sets pre_enable_prev_first, then the post_disable for that bridge gets called before the previous one, so it reverses the pre_enable calling direction. cute right? symmetry slay 💅

🌈 EXAMPLE 🌈

picture this chain, iconic lineup honestly:

Bridge A ---> Bridge B ---> Bridge C ---> Bridge D ---> Bridge E

With the pre_enable_prev_first flag enabled in Bridge B, D, E, then the resulting post_disable order would be:

Bridge B, Bridge A, Bridge E, Bridge D, Bridge C.

not me re-reading that twice 😭 it flips, bestie, that's the whole vibe.

🩷 NOTE 🩷

the bridge passed should be the one closest to the encoder 👀 don't hand it a random middle bridge, that's not it.

👑 SEE ALSO 👑

the whole friend group, go say hi 💜

okay that's the whole page bestie, go forth and disable your bridges in the correct order 🦋💖✨

this came from ./drivers/gpu/drm, dated October 2026, and it's drm_atomic_b...post_disable(9) — mwah, love u, bye 💅🎀

📦 where this page comes from