Hotplug(9)

💅 Hotplug 💅

okay so bestie, welcome to Hotplug(9) — it lives in the Kernel API Manual and honestly it's lowkey one of those pages that sounds simple and then immediately gets complicated. buckle up 🎀

---

🦋 the vibe check

Simply put, hotplug occurs when a display is connected to or disconnected from the system. that's it. that's the tweet. ✨

but 😭 there may be adapters and docking stations and Display Port short pulses and MST devices involved, complicating matters. so yeah, "simply put" is doing a lot of heavy lifting in that sentence.

Hotplug in i915 is handled in many different levels of abstraction. like, layers on layers on layers. it's giving onion. 🧅

• the platform dependent interrupt handling code in i915_irq.c enables, disables, and does preliminary handling of the interrupts. the interrupt handlers gather the hotplug detect (HPD) information from relevant registers into a platform independent mask of hotplug pins that have fired. iconic behavior honestly.
• the platform independent interrupt handler intel_hpd_irq_handler in intel_hotplug.c does hotplug irq storm detection and mitigation, and passes further processing to appropriate bottom halves (Display Port specific and regular hotplug). she's the middle manager of this whole operation 💅
• the Display Port work function i915_digport_work_func calls into intel_dp_hpd_pulse via hooks, which handles DP short pulses and DP MST long pulses, with failures and non-MST long pulses triggering regular hotplug processing on the connector. ate. 🔥
• the regular hotplug work function i915_hotplug_work_func calls connector detect hooks, and, if connector status changes, triggers sending of hotplug uevent to userspace via drm_kms_helper_hotplug_event. 👑
• finally, the userspace is responsible for triggering a modeset upon receiving the hotplug uevent, disabling or enabling the crtc as needed. so yeah — userspace has to do her part too, no cap.

---

🌈 the interrupt storm part (the dramatic one)

The hotplug interrupt storm detection and mitigation code keeps track of the number of interrupts per hotplug pin per a period of time, and if the number of interrupts exceeds a certain threshold, the interrupt is disabled for a while before being re-enabled.

The intention is to mitigate issues raising from broken hardware triggering massive amounts of interrupts and grinding the system to a halt. 💀 so if your box is mysteriously dying, that's the nightmare scenario this code is literally fighting against. she's a bodyguard fr fr.

Current implementation expects that hotplug interrupt storm will not be seen when display port sink is connected, hence on platforms whose DP callback is handled by i915_digport_work_func reenabling of hpd is not performed (it was never expected to be disabled in the first place ;) )

bestie read that again — the reenabling doesn't happen because they never expected it to be disabled at all. the ;) is doing emotional damage but it's fine 🙈

this is specific to DP sinks handled by this routine and any other display such as HDMI or DVI enabled on the same port will have proper logic since it will use i915_hotplug_work_func where this logic is handled. ✨ so like, same port, different display type, different pathway. iykyk.

---

🌸 SEE ALSO 🌸

• Kernel file ./drivers/gpu/drm/i915/display/intel_hotplug.c
• intel_hpd_pin_default(9)
• intel_hpd_irq_storm_detect(9)
• intel_hpd_trigger_irq(9)
• intel_hpd_irq_handler(9)
• intel_hpd_init(9)
• intel_hpd_poll_enable(9)
• intel_hpd_poll_disable(9)
• intel_hpd_block(9)
• intel_hpd_unblock(9)
• intel_hpd_clear_and_unblock(9)

---

🫶 and that's the whole page bestie! this one came from ./drivers/gpu/drm/i915/display, dated October 2026, and yes the header still says Hotplug(9) because some things never change 💜 go read those SEE ALSOs, they're literally all right there ⭐