STRUCT PANEL_DELAY(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct panel_delay(9) β€” like, the whole Kernel API Manual moment ✨

okay so bestie, welcome to struct panel_delay β€” the little struct that literally just describes delays for a simple panel. That's it. That's the whole vibe. It's a timing sheet for your screen, and honestly it's giving "backstage pass to the panel" πŸŽ€


✨ SYNOPSIS ✨

struct panel_delay {
    unsigned int hpd_reliable;
    unsigned int hpd_absent;
    unsigned int powered_on_to_enable;
    unsigned int prepare_to_enable;
    unsigned int enable;
    unsigned int disable;
    unsigned int pre_unprepare;
    unsigned int unprepare;
 };

look at her. eight unsigned int fields, all milliseconds, all main character energy πŸ‘‘


🌸 Members 🌸

  • hpd_reliable β€” time for HPD to be reliable πŸ’–
  • hpd_absent β€” time to wait if HPD isn't hooked up πŸ™ˆ
  • powered_on_to_enable β€” time between panel powered on and enable ⚑
  • prepare_to_enable β€” time between prepare and enable πŸ¦‹
  • enable β€” time for the panel to display a valid frame ✨
  • disable β€” time for the panel to turn the display off πŸ’€
  • pre_unprepare β€” time for the end of video data to power off πŸ”Œ
  • unprepare β€” time to power down completely πŸ’€

now let's actually go through them one by one, because the details MATTER 🫢


hpd_reliable β€” time for HPD to be reliable

The time (in milliseconds) that it takes after powering the panel before the HPD signal is reliable. Ideally this is 0 β€” but bestie, some panels, board designs, or bad pulldown configs can cause a glitch here. 😭

NOTE: on some old panel data this number appears to be much too big. Presumably some old panels simply didn't have HPD hooked up and put the hpd_absent here because this field predates the hpd_absent. While that works, it's non-ideal. ngl that's a legacy-code jumpscare πŸ™ˆ

hpd_absent β€” time to wait if HPD isn't hooked up

Add this to the prepare delay if we know Hot Plug Detect isn't used.

This is T3-max on eDP timing diagrams, or the delay from power on until HPD is guaranteed to be asserted. πŸ“Œ


powered_on_to_enable β€” time between panel powered on and enable

The minimum time, in milliseconds, that needs to have passed between when panel powered on and enable may begin. ⏳

This is (T3+T4+T5+T6+T8)-min on eDP timing diagrams β€” or, in human terms, after the power supply enabled until we can turn the backlight on and see valid data. πŸ”₯

This doesn't normally need to be set if timings are already met by prepare_to_enable or enable. so like... don't overthink it πŸ’…

prepare_to_enable β€” time between prepare and enable

The minimum time, in milliseconds, that needs to have passed between when prepare finished and enable may begin. If at enable time less time has passed since prepare finished, the driver waits for the remaining time. ⏲️

If a fixed enable delay is also specified, we'll start counting before delaying for the fixed delay.

If a fixed prepare delay is also specified, we won't start counting until after the fixed delay. We can't overlap this fixed delay with the min time because the fixed delay doesn't happen at the end of the function if a HPD GPIO was specified. 😀

In other words:

prepare ...  // do fixed prepare delay // wait for HPD
GPIO if applicable // start counting for prepare_to_enable

enable // do fixed enable delay // enforce prepare_to_enable min time

This is usually (T4+T5+T6+T8)-min on eDP timing diagrams. It is effectively the time from HPD going high till you can turn on the backlight. 🌈


enable β€” time for the panel to display a valid frame

The time (in milliseconds) that it takes for the panel to display the first valid frame after starting to receive video data. 🎬

This is (T6-min + max(T7-max, T8-min)) on eDP timing diagrams β€” or the delay after link training finishes until we can turn the backlight on and see valid data. yes there's a nested max() in there, she's iconic like that πŸ‘‘


disable β€” time for the panel to turn the display off

The time (in milliseconds) that it takes for the panel to turn the display off (no content is visible). πŸ’€

This is T9-min (delay from backlight off to end of valid video data) on eDP timing diagrams. It is not common to set. so like, lowkey optional πŸŒ™


pre_unprepare β€” time for the end of video data to power off

The time (in milliseconds) that it needs to have passed between the end of valid video data from source and start powering off. πŸ”Œ

This is T10-min on eDP timing diagrams. It is not common to set. same energy, honestly πŸ“


unprepare β€” time to power down completely

The time (in milliseconds) that it takes for the panel to power itself down completely. πŸ’€

This time is used to prevent a future "prepare" from starting until at least this many milliseconds has passed. If at prepare time less time has passed since unprepare finished, the driver waits for the remaining time. ⏰

This is T12-min on eDP timing diagrams. πŸŽ€


πŸ‘€ SEE ALSO πŸ‘€

  • Kernel file ./drivers/gpu/drm/panel/panel-edp.c
  • struct panel_desc(9)
  • struct edp_panel_entry(9)

and that's the page bestie!! 🫢 this one lives in ./drivers/gpu/drm/panel, stamped October 2026, and it's from the Kernel API Manual β€” struct panel_delay(9), fr fr. go take a nap, you've earned it πŸ˜­πŸ’œ

πŸ“¦ where this page comes from