Re: [PATCH] drm/panel-edp: Add pre_unprepare delay

Doug Anderson <[email protected]> Mon, 3 Aug 2026 12:50:11 -0700
Newsgroups org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel
Message-ID <CAD=FV=XeW806uSg5JM95qHrfKUKXpC_z9BUaDv61wu0KGFry5A@mail.gmail.com>
Hi,

On Mon, Aug 3, 2026 at 2:47=E2=80=AFAM Hsin-Te Yuan <[email protected]=
g> wrote:
>
> In eDP power-off timing specifications, T10 defines the minimum delay
> required between the end of valid video data from the source and panel
> power-down (main VDD off).
>
> Currently, panel-edp only supports the 'disable' delay, which corresponds
> to T9 (backlight off to end of video data) and runs in panel_edp_disable(=
)
> while video data is still active. For panels that require a delay after
> video data has stopped before cutting power, this delay must occur in
> panel_edp_unprepare() before turning off power rails.
>
> Add a 'pre_unprepare' field to struct panel_delay to model T10-min, and
> delay for this duration in panel_edp_unprepare() before calling
> pm_runtime_put_sync_suspend().
>
> Additionally, adjust the timing entry for TM156VDXP25 to use
> delay_200_500_e80_pu100 (enable =3D 80ms, pre_unprepare =3D 100ms) to mat=
ch
> its panel specification, replacing the previous delay_200_500_e50_d100.
>
> Fixes: b9e2d5cdaab0 ("drm/panel-edp: Support NV140FHM-N5B and TM156VDXP25=
")
> Signed-off-by: Hsin-Te Yuan <[email protected]>
> ---
> Change-Id: I3361bdf4d3289c773f0c2b77163e427b774797d5
> ---
>  drivers/gpu/drm/panel/panel-edp.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/pa=
nel-edp.c
> index 98bdcf352701..f6624191f97c 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -144,6 +144,16 @@ struct panel_delay {
>          */
>         unsigned int disable;
>
> +       /**
> +        * @pre_unprepare: Time for the end of video data to power off.
> +        *
> +        * The time (in milliseconds) that it needs to have passed betwee=
n
> +        * 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 se=
t.
> +        */
> +       unsigned int pre_unprepare;
> +
>         /**
>          * @unprepare: Time to power down completely.
>          *
> @@ -413,8 +423,12 @@ static int panel_edp_suspend(struct device *dev)
>
>  static int panel_edp_unprepare(struct drm_panel *panel)
>  {
> +       struct panel_edp *p =3D to_panel_edp(panel);
>         int ret;
>
> +       if (p->desc->delay.pre_unprepare)
> +               msleep(p->desc->delay.pre_unprepare);
> +
>         ret =3D pm_runtime_put_sync_suspend(panel->dev);
>         if (ret < 0)
>                 return ret;
> @@ -1810,6 +1824,13 @@ static const struct panel_delay delay_80_500_e80_p=
2e200 =3D {
>         .prepare_to_enable =3D 200,
>  };
>
> +static const struct panel_delay delay_200_500_e80_pu100 =3D {
> +       .hpd_absent =3D 200,
> +       .unprepare =3D 500,
> +       .enable =3D 80,
> +       .pre_unprepare =3D 100,
> +};
> +
>  static const struct panel_delay delay_100_500_e200 =3D {
>         .hpd_absent =3D 100,
>         .unprepare =3D 500,
> @@ -2181,7 +2202,7 @@ static const struct edp_panel_entry edp_panels[] =
=3D {
>
>         EDP_PANEL_ENTRY('T', 'M', 'A', 0x0811, &delay_200_500_e80_d50, "T=
M140VDXP01-04"),
>         EDP_PANEL_ENTRY('T', 'M', 'A', 0x2094, &delay_200_500_e50_d100, "=
TL140VDMS03-01"),
> -       EDP_PANEL_ENTRY('T', 'M', 'A', 0x2139, &delay_200_500_e50_d100, "=
TM156VDXP25"),
> +       EDP_PANEL_ENTRY('T', 'M', 'A', 0x2139, &delay_200_500_e80_pu100, =
"TM156VDXP25"),

Looks OK to me. Thank you for the thorough description.

Reviewed-by: Douglas Anderson <[email protected]>

Do you happen to know if any of the other TMA panels should also get
this updated timing?


My thought would be to land this in drm-misc-next instead of
drm-misc-fixes. Is that OK w/ you? I assume you just need a stable git
hash to pick and it's not urgent for you to get this in through stable
trees. Getting the updated timings is usually not massively
time-critical and having bake time / avoiding merge conflicts is
nice...

Assuming nothing else comes up, I'll try to land in the next few days.
Usually I don't delay at all for panel timings, but since this changes
an old panel I'll at least give it an extra day or two...

-Doug