STRUCT DRM_DP_MST_ATOMIC_PAYLOAD(9)

💅 struct drm_dp_mst_atomic_payload(9) — the Kernel API Manual glow-up ✨

okay so bestie, this is from the Kernel API Manual, and today's main character is struct drm_dp_mst_atomic_payload. let's get into it 🎀

---

✨ NAME ✨

struct drm_dp_mst_atomic_payload — the atomic state struct for an MST payload. yes that's the whole vibe, she's the state-holder for one MST payload 💖

---

🌸 SYNOPSIS 🌸

struct drm_dp_mst_atomic_payload {
    struct drm_dp_mst_port *port;
    s8 vc_start_slot;
    u8 vcpi;
    int time_slots;
    int pbn;
    bool delete : 1;
    bool dsc_enabled : 1;
    enum drm_dp_mst_payload_allocation payload_allocation_status;
    struct list_head next;
 };

---

🦋 Members 🦋

• port — the MST port that's assigned to this payload. she's taken 💅
• vc_start_slot — the time slot this payload starts on. and here's the gag: because payload start slots literally cannot be figured out ahead of time, the contents of this value are UNDEFINED at atomic check time. 😭 and honestly? usually nobody cares, because the start slot should never matter for atomic state computations anyway.

so since this value gets determined at commit time and not check time, it's protected by the MST helpers making sure that async commits working on the given topology never run in parallel. but if a driver does need to read this value (like, to tell hardware the starting timeslot for a payload), the driver has two options:

• read this field during the atomic commit, after drm_dp_mst_atomic_wait_for_dependencies has been called — that guarantees the previous MST states' payload start slots have already been copied over to the new state. just know that a new start slot won't be assigned or removed from this payload until drm_dp_add_payload_part1/drm_dp_remove_payload_part2 have been called 🔥
• acquire the MST modesetting lock, then wait for any pending MST-related commits to get committed to hardware by calling drm_crtc_commit_wait on each of the drm_crtc_commit structs in drm_dp_mst_topology_state.commit_deps

and if neither of those two solutions is enough for you (like, the driver needs to read the start slot mid-atomic-commit without waiting, for some reason 🙈)? then the driver should cache this value itself after changing payloads. no cap.

• vcpi — the Virtual Channel Payload Identifier 🆔
• time_slots — the number of timeslots allocated to this payload, from the source DP Tx to the immediate downstream DP Rx
• pbn — the payload bandwidth for this payload 📶
• delete — whether or not we intend to delete this payload during this atomic commit. it's giving "should we remove her"
• dsc_enabled — whether or not this payload has DSC enabled
• payload_allocation_status — the allocation status of this payload
• next — the list node for this payload, a.k.a. the link in the chain 🔗

---

👑 Description 👑

she's the primary atomic state structure for a given MST payload. 💅 stores information like the current bandwidth allocation, the intended action for this payload, etc. literally the main character energy of the payload world, periodt.

---

🌈 SEE ALSO 🌈

kernel file ./include/drm/display/drm_dp_mst_helper.h, plus these icons:

• struct drm_dp_mst_port(9)
• struct drm_dp_mst_branch(9)
• struct drm_dp_mst_topology_state(9)
• struct drm_dp_mst_topology_mgr(9)
• enum drm_dp_mst_mode(9)
• __drm_dp_mst_state_iter_get(9)
• for_each_oldnew_mst_mgr_in_state(9)
• for_each_old_mst_mgr_in_state(9)
• for_each_new_mst_mgr_in_state(9)

---

okay that's the whole page bestie, go read the source, mwah 🫶💖

sourced from ./include/drm/display, dated October 2026, and it's still struct drm_dp_mst_atomic_payload(9) at the end of the day ✨