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

[Alexandre Marquet]

Hi,

Le Thu, Oct 29, 2026 at 04:27:30PM -0700, Doug Anderson a écrit :
> 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.

I was referring to the post-pwm-on-delay-ms property of pwm-backlight.
But I tested without this property, and with .enable set to 97ms, and 
could not find any difference in behaviour.

> 
> 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?

Indeed. Also having the 97ms value from the downstream code in .enable
removes the guessing associated with the 50ms in my initial proposal. So
I will implement this in v2.

Any preference as to where I should put the new delay_200_500_e97
panel_delay struct? I was thinking after delay_200_500_e80_d50, but
I noticed that the delays are not strictly in alphabetical order.

Thank you again for your review,
Best regards,
Alex.