[PATCH v1 3/3] drm/panel-edp: Add BOE NV140WUM-N64

[Doug Anderson]

Hi,

On Wed, Jul 30, 2025 at 1:38 PM Aleksandrs Vinarskis
<alex.vinarskis at gmail.com> wrote:
>
> On Tue, 29 Jul 2025 at 17:50, Doug Anderson <dianders at chromium.org> wrote:
> >
> > Hi,
> >
> > On Sun, Jul 27, 2025 at 9:58 AM Aleksandrs Vinarskis
> > <alex.vinarskis at 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.vinarskis at 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.

...and the "p2e80" doesn't do anything useful when enable is 200.


-Doug