amdgpu_dm_atomic_check(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… amdgpu_dm_atomic_check(9)

okay so bestie, welcome to the amdgpu_dm_atomic_check(9) page β€” yes that's the manual name, it lives in the Kernel API Manual, and no I'm not gonna make you read the boring header twice. sit down, hydrate, let's go ✨


🌸 NAME 🌸

amdgpu_dm_atomic_check β€” the atomic check implementation for AMDgpu DM. that's it, that's the whole vibe. it's the bouncer at the club door of hardware state changes πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

int amdgpu_dm_atomic_check (struct drm_device *dev , struct
       drm_atomic_commit *state );

like… look at her. two args, one int coming back. iconic.


πŸ¦‹ ARGUMENTS πŸ¦‹

  • dev β€” the DRM device. the whole main character of the graphics world, honestly.
  • state β€” the atomic state that we're trying to commit. this is the thing getting the full vibe check.

✨ DESCRIPTION ✨

okay so the entire job here is: validate that the given atomic state is actually programmable by DC into the hardware. that's the assignment. that's the whole point of her.

how does she do it? she constructs a struct dc_state that reflects the new hardware state we wish to commit, and then she goes and queries DC to see if it's programmable. boom. that's the flow 🫢

⚠️ and this part is so important bestie β€” do not modify the existing DC state. like, don't. because if you do, atomic_check may unexpectedly commit hardware changes, and that is not the slay we're going for 😭

when validating the DC state, it's super important that the right locks are acquired. fr fr. specifically for the full updates case β€” the one that removes/adds/updates streams on one CRTC while flipping on another CRTC β€” acquiring the global lock will guarantee that any such full update commit will wait for completion of any outstanding flip, using DRM's synchronization events. no cap, that's the guarantee you get. πŸ”₯

also, heads up: DM adds the affected connectors for all CRTCs in state, even when that might not seem necessary. why? because DC stream creation requires the DC sink, which is tied to the DRM connector state. so yeah, it looks extra but it's not being extra for no reason. cleaning this up should be possible but it's non-trivial β€” a possible TODO item, as the original so politely puts it πŸ‘€


⭐ RETURN ⭐

  • -Error code if validation failed. that's it. if she fails, you get the error code, periodt.

πŸ’œ SEE ALSO πŸ’œ

kernel file ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c β€” go read it, iykyk 🧚

then the friend group:


and that's the page bestie!! πŸ“ she comes from the kernel tree at ./drivers/gpu/drm/amd/display/..., dated October 2026, and yes the footer still says amdgpu_dm_atomic_check(9) because she's consistent like that πŸ‘‘ thanks for reading, go validate some atomic state, mwah πŸ’–

πŸ“¦ where this page comes from