[PATCH 3/3] drm/panel_edp: Add SEC LTL101DL02-002 panel

Doug Anderson dianders at chromium.org
Thu Oct 29 16:27:30 PDT 2026


Hi,

On Thu, Oct 29, 2026 at 1:55 PM Alexandre Marquet <tb at a-marquet.fr> 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?



More information about the linux-arm-kernel mailing list