Hi, On Thu, Oct 29, 2026 at 1:55 PM Alexandre Marquet <[email protected]> wrote: > > > > diff --git a/drivers/gpu/drm/panel/panel-edp.c > > > b/drivers/gpu/drm/panel/panel-edp.c > > > index 94bc54c3833a..c92985363093 100644 > > > --- a/drivers/gpu/drm/panel/panel-edp.c > > > +++ b/drivers/gpu/drm/panel/panel-edp.c > > > @@ -2198,6 +2198,8 @@ static const struct edp_panel_entry edp_panels[] = { > > > EDP_PANEL_ENTRY('L', 'G', 'D', 0x0778, &delay_200_500_e200_d200, > > > "134WT1"), > > > EDP_PANEL_ENTRY('L', 'G', 'D', 0x07fe, &delay_200_500_e200_d200, > > > "LP116WHA-SPB1"), > > > > > > + EDP_PANEL_ENTRY('S', 'E', 'C', 0x9c0f, &delay_200_500_e50, > > > "LTL101DL02-002"), > > > + > > > > It would also be good to note in the commit message where you got the > > timings from. Datasheet? Downstream code? Guessing? > > Both downstream code and guessing, as I could not get my hand on a > datasheet. I will add an explanation to the commit description. > > Basically, the downstream code waits: at least 500ms before toggling the > LCD_EN > GPIO for power on; and 200ms after. I matched the 200ms to the hpd_absent > delay, since in panel-edp.c, hpd_absent is also the delay that happens > right after enabling the LCD regulator (or toggling the enable GPIO, as > appropriate). Similarly, the unprepare delay is called just before > enabling the LCD regulator, through panel_edp_wait(), which matches the > way the 500ms delay is used in the downstream code. > > For the enable delay, I went with the smallest value that would still > work, but I admit that I did not try anything below 50ms. > > > > > I had my AI agent take a look for itself. It found evidence suggesting > > the enable delay should be 97ms, not 50ms. The other ones seem to be > > OK. > > In the downstream code, 97ms is the delay used before setting the > backlight on. My understanding is that this should be used elsewhere > (e.g.: in the backlight node of the device's DTS).
I don't believe I've ever seen a delay in the backlight node of the device's DTS, so that sounds wrong. The .enable delay here is described as: /** * @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. */ That sounds like exactly what you're looking for, no?
