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