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@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"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0cfa, &delay_200_500_e50, "NV116WHM-A4D"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0d73, &delay_200_500_e80, "NE140WUM-N6S"),
--
2.48.1
Hi, On Sun, Jul 27, 2025 at 9:58 AM Aleksandrs Vinarskis <alex.vinarskis@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@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? -Doug
On Tue, 29 Jul 2025 at 17:50, Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Sun, Jul 27, 2025 at 9:58 AM Aleksandrs Vinarskis > <alex.vinarskis@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@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. Thanks, Alex > > -Doug
Hi, On Wed, Jul 30, 2025 at 1:38 PM Aleksandrs Vinarskis <alex.vinarskis@gmail.com> wrote: > > On Tue, 29 Jul 2025 at 17:50, Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Sun, Jul 27, 2025 at 9:58 AM Aleksandrs Vinarskis > > <alex.vinarskis@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@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
On Wed, 30 Jul 2025 at 23:44, Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Jul 30, 2025 at 1:38 PM Aleksandrs Vinarskis > <alex.vinarskis@gmail.com> wrote: > > > > On Tue, 29 Jul 2025 at 17:50, Doug Anderson <dianders@chromium.org> wrote: > > > > > > Hi, > > > > > > On Sun, Jul 27, 2025 at 9:58 AM Aleksandrs Vinarskis > > > <alex.vinarskis@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@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
© 2016 - 2025 Red Hat, Inc.