On Wed, 30 Jul 2025 at 23:44, Doug Anderson <diand...@chromium.org> wrote:
>
> Hi,
>
> On Wed, Jul 30, 2025 at 1:38 PM Aleksandrs Vinarskis
> <alex.vinars...@gmail.com> wrote:
> >
> > On Tue, 29 Jul 2025 at 17:50, Doug Anderson <diand...@chromium.org> wrote:
> > >
> > > Hi,
> > >
> > > On Sun, Jul 27, 2025 at 9:58 AM Aleksandrs Vinarskis
> > > <alex.vinars...@gmail.com> wrote:
> > > >
> > > > Timings taken from NV140WUM-N41. It is found in some arm64 laptops,
> > > > eg. Asus Zenbook A14 UX3407QA.
> > > >
> > > > The raw edid of the panel is:
> > > > 00 ff ff ff ff ff ff 00 09 e5 f6 0c 00 00 00 00
> > > > 10 22 01 04 a5 1e 13 78 07 8e 95 a6 52 4c 9d 26
> > > > 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> > > > 01 01 01 01 01 01 5d 30 80 a0 70 b0 28 40 30 20
> > > > 36 00 2e bc 10 00 00 1a 00 00 00 fd 00 28 3c 4a
> > > > 4a 0f 01 0a 20 20 20 20 20 20 00 00 00 fe 00 3d
> > > > 4c 33 30 20 20 20 20 20 20 20 20 ff 00 00 00 fc
> > > > 00 4e 56 31 34 30 57 55 4d 2d 4e 36 34 0a 01 f8
> > > >
> > > > 70 20 79 02 00 21 00 1d c8 0b 5d 07 80 07 b0 04
> > > > 88 66 ea 51 cc 74 9d 66 52 0f 02 35 54 40 5e 40
> > > > 5e 00 44 12 78 22 00 14 7f 5c 02 85 7f 07 9f 00
> > > > 2f 00 1f 00 af 04 27 00 02 00 05 00 2b 00 0c 27
> > > > 00 28 3b 00 00 27 00 28 2f 00 00 2e 00 06 00 44
> > > > 40 5e 40 5e 81 00 1e 72 1a 00 00 03 71 28 3c 00
> > > > 00 60 ff 60 ff 3c 00 00 00 00 e3 05 04 00 e6 06
> > > > 01 01 60 60 ff 00 00 00 00 00 00 00 00 00 de 90
> > > >
> > > > Signed-off-by: Aleksandrs Vinarskis <alex.vinars...@gmail.com>
> > > > ---
> > > > drivers/gpu/drm/panel/panel-edp.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/panel/panel-edp.c
> > > > b/drivers/gpu/drm/panel/panel-edp.c
> > > > index 9a56e208cbdd..b334926e96ed 100644
> > > > --- a/drivers/gpu/drm/panel/panel-edp.c
> > > > +++ b/drivers/gpu/drm/panel/panel-edp.c
> > > > @@ -1947,6 +1947,7 @@ static const struct edp_panel_entry edp_panels[]
> > > > = {
> > > > EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c20, &delay_200_500_e80,
> > > > "NT140FHM-N47"),
> > > > EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c93, &delay_200_500_e200,
> > > > "Unknown"),
> > > > EDP_PANEL_ENTRY('B', 'O', 'E', 0x0cb6, &delay_200_500_e200,
> > > > "NT116WHM-N44"),
> > > > + EDP_PANEL_ENTRY('B', 'O', 'E', 0x0cf6,
> > > > &delay_200_500_e50_p2e80, "NV140WUM-N64"),
> > >
> > > Since this is a "guess" timing without any datasheet, I'd be more
> > > comfortable picking the most conservative of the "cousin" timings. Can
> > > you re-send with "delay_200_500_e200" instead?
> >
> > Sure.
> >
> > Do I understand correctly that more conservative delay_200_500_e200
> > will for sure not make it worse, since its more conservative? In that
> > case can re-spin right away. Otherwise I would prefer to re-test it
> > first, may take a few days as I do not own the hardware so need to
> > propagate the change and get some feedback.
>
> Is anything really for sure? No. :-)
>
> ...but it's _highly_ likely to not make it worse. Presumably you
> tested without ${SUBJECT} patch and things worked OK aside from the
> big warning splat in your logs about using the conservative timings.
> Those conservative timings basically give you:
>
> desc->delay.enable = 200;
>
> ...so you probably already tested with an enable timing of 200 and
> using 200 here will give you the same conservative number for
> "enable", will avoid some other conservative timings, and will avoid
> the warning splat.
Indeed, this is mostly to get rid of the warning, and it worked
perfectly fine without adjusted timings.
Thanks for the explanation! Will re-spin shortly.
Alex
>
> ...and the "p2e80" doesn't do anything useful when enable is 200.
>
>
> -Doug
