[PATCH 00/33] drm/panel: Fix dotclocks

[PATCH 00/33] drm/panel: Fix dotclocks

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

A lot of the panel drivers put bogus looking values into
mode.clock. This series replaces the bogus values with
mode.vrefresh*mode.htotal*mode.vtotal.

Now, that may not be the right choice in all cases. There
are quite a few cases where the error looks very minor and
it may be that mode.vrefresh was just miscalculated. But
other cases show huge discepancies. Either way I want to
know which way we should go.

I need to get these sorted one way or the other to
land the drm_display_mode diet patches.

Entire series available here:
git://github.com/vsyrjala/linux.git mode_clock_vs_vrefresh

Ville Syrjälä (33):
  drm/panel-novatek-nt35510: Fix dotclock
  drm/panel-arm-versatile: Fix dotclock
  drm/panel-feixin-k101-im2ba02: Fix dotclock
  drm/panel-ilitek-ili9322: Fix dotclocks
  drm/panel-leadtek-ltk500hd1829: Fix dotclock
  drm/panel-lg-lg4573: Fix dotclock
  drm/panel-sitronix-st7789v: Fix dotclock
  drm/panel-sony-acx424akp: Fix dotclocks
  drm/panel-simple: Fix dotclock for AUO G101EVN010
  drm/panel-simple: Fix dotclock for AUO G104SN02 V2
  drm/panel-simple: Fix dotclock for CDTech S043WQ26H-CT7
  drm/panel-simple: Fix dotclock for CDTech S070WV95-CT16
  drm/panel-simple: Fix dotclock for Chunghwa CLAA070WP03XG
  drm/panel-simple: Fix dotclock for Chunghwa Picture Tubes 10.1" WXGA
  drm/panel-simple: Fix dotclock for EDT ET035012DM6
  drm/panel-simple: Fix dotclock for EDT ET043080DH6-GP
  drm/panel-simple: Fix dotclock for Foxlink FL500WVR00-A0T
  drm/panel-simple: Fix dotclock for Giantplus GPG482739QS5
  drm/panel-simple: Fix dotclock for Innolux AT070TN92
  drm/panel-simple: Fix dotclock for LeMaker BL035-RGB-002 3.5" LCD
  drm/panel-simple: Fix dotclock for Logic PD Type 28
  drm/panel-simple: Fix dotclock for Netron DY E231732
  drm/panel-simple: Fix dotclock for On Tat Industrial Company 7" DPI
    TFT
  drm/panel-simple: Fix dotclock for Ortustech COM37H3M
  drm/panel-simple: Fix dotclock for PDA 91-00156-A0
  drm/panel-simple: Fix dotclock for QiaoDian qd43003c0-40
  drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03
  drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
  drm/panel-simple: Fix dotclock for Shelly SCA07010-BFN-LNN
  drm/panel-simple: Fix dotclock for TPK U.S.A. LLC Fusion
  drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01
  drm/panel-simple: Fix dotclock for LG LH500WX1-SD03
  drm/panel-simple: Fix dotclock for LG ACX467AKM-7

 drivers/gpu/drm/panel/panel-arm-versatile.c   |  6 +--
 .../gpu/drm/panel/panel-feixin-k101-im2ba02.c |  2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c  | 14 +++---
 .../drm/panel/panel-leadtek-ltk500hd1829.c    |  2 +-
 drivers/gpu/drm/panel/panel-lg-lg4573.c       |  2 +-
 drivers/gpu/drm/panel/panel-novatek-nt35510.c |  2 +-
 drivers/gpu/drm/panel/panel-simple.c          | 50 +++++++++----------
 .../gpu/drm/panel/panel-sitronix-st7789v.c    |  2 +-
 drivers/gpu/drm/panel/panel-sony-acx424akp.c  |  4 +-
 9 files changed, 42 insertions(+), 42 deletions(-)

-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index b4c014126781..94e294b66a6a 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -1019,7 +1019,7 @@ static const struct nt35510_config nt35510_hydis_hva40wv1 = {
 	 */
 	.mode = {
 		/* The internal pixel clock of the NT35510 is 20 MHz */
-		.clock = 20000000,
+		.clock = 23581,
 		.hdisplay = 480,
 		.hsync_start = 480 + 2, /* HFP = 2 */
 		.hsync_end = 480 + 2 + 0, /* HSync = 0 */
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/33] drm/panel-arm-versatile: Fix dotclock

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-arm-versatile.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c b/drivers/gpu/drm/panel/panel-arm-versatile.c
index 41444a73c980..ef49ba206eea 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -158,7 +158,7 @@ static const struct versatile_panel_type versatile_panels[] = {
 		.width_mm = 171,
 		.height_mm = 130,
 		.mode = {
-			.clock = 25000,
+			.clock = 24696,
 			.hdisplay = 640,
 			.hsync_start = 640 + 24,
 			.hsync_end = 640 + 24 + 96,
@@ -181,7 +181,7 @@ static const struct versatile_panel_type versatile_panels[] = {
 		.width_mm = 34,
 		.height_mm = 45,
 		.mode = {
-			.clock = 62500,
+			.clock = 16002,
 			.hdisplay = 176,
 			.hsync_start = 176 + 2,
 			.hsync_end = 176 + 2 + 3,
@@ -205,7 +205,7 @@ static const struct versatile_panel_type versatile_panels[] = {
 		.width_mm = 37,
 		.height_mm = 50,
 		.mode = {
-			.clock = 5400,
+			.clock = 10588,
 			.hdisplay = 240,
 			.hsync_start = 240 + 10,
 			.hsync_end = 240 + 10 + 10,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
index fddbfddf6566..8debee85f4ec 100644
--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel *panel)
 }
 
 static const struct drm_display_mode k101_im2ba02_default_mode = {
-	.clock = 70000,
+	.clock = 67286,
 	.vrefresh = 60,
 
 	.hdisplay = 800,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index f394d53a7da4..5e06e73c2517 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -540,7 +540,7 @@ static int ili9322_enable(struct drm_panel *panel)
 
 /* Serial RGB modes */
 static const struct drm_display_mode srgb_320x240_mode = {
-	.clock = 2453500,
+	.clock = 14478,
 	.hdisplay = 320,
 	.hsync_start = 320 + 359,
 	.hsync_end = 320 + 359 + 1,
@@ -554,7 +554,7 @@ static const struct drm_display_mode srgb_320x240_mode = {
 };
 
 static const struct drm_display_mode srgb_360x240_mode = {
-	.clock = 2700000,
+	.clock = 10014,
 	.hdisplay = 360,
 	.hsync_start = 360 + 35,
 	.hsync_end = 360 + 35 + 1,
@@ -569,7 +569,7 @@ static const struct drm_display_mode srgb_360x240_mode = {
 
 /* This is the only mode listed for parallel RGB in the datasheet */
 static const struct drm_display_mode prgb_320x240_mode = {
-	.clock = 6400000,
+	.clock = 6429,
 	.hdisplay = 320,
 	.hsync_start = 320 + 38,
 	.hsync_end = 320 + 38 + 1,
@@ -584,7 +584,7 @@ static const struct drm_display_mode prgb_320x240_mode = {
 
 /* YUV modes */
 static const struct drm_display_mode yuv_640x320_mode = {
-	.clock = 2454000,
+	.clock = 18954,
 	.hdisplay = 640,
 	.hsync_start = 640 + 252,
 	.hsync_end = 640 + 252 + 1,
@@ -598,7 +598,7 @@ static const struct drm_display_mode yuv_640x320_mode = {
 };
 
 static const struct drm_display_mode yuv_720x360_mode = {
-	.clock = 2700000,
+	.clock = 22911,
 	.hdisplay = 720,
 	.hsync_start = 720 + 252,
 	.hsync_end = 720 + 252 + 1,
@@ -613,7 +613,7 @@ static const struct drm_display_mode yuv_720x360_mode = {
 
 /* BT.656 VGA mode, 640x480 */
 static const struct drm_display_mode itu_r_bt_656_640_mode = {
-	.clock = 2454000,
+	.clock = 27480,
 	.hdisplay = 640,
 	.hsync_start = 640 + 3,
 	.hsync_end = 640 + 3 + 1,
@@ -628,7 +628,7 @@ static const struct drm_display_mode itu_r_bt_656_640_mode = {
 
 /* BT.656 D1 mode 720x480 */
 static const struct drm_display_mode itu_r_bt_656_720_mode = {
-	.clock = 2700000,
+	.clock = 29880,
 	.hdisplay = 720,
 	.hsync_start = 720 + 3,
 	.hsync_end = 720 + 3 + 1,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
index 76ecf2de9c44..113ab9c0396b 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
@@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
 	.vsync_end	= 1280 + 30 + 4,
 	.vtotal		= 1280 + 30 + 4 + 12,
 	.vrefresh	= 60,
-	.clock		= 41600,
+	.clock		= 69217,
 	.width_mm	= 62,
 	.height_mm	= 110,
 };
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/33] drm/panel-lg-lg4573: Fix dotclock

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Heiko Schocher <hs@denx.de>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-lg-lg4573.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-lg-lg4573.c b/drivers/gpu/drm/panel/panel-lg-lg4573.c
index b262b53dbd85..5907f2503755 100644
--- a/drivers/gpu/drm/panel/panel-lg-lg4573.c
+++ b/drivers/gpu/drm/panel/panel-lg-lg4573.c
@@ -197,7 +197,7 @@ static int lg4573_enable(struct drm_panel *panel)
 }
 
 static const struct drm_display_mode default_mode = {
-	.clock = 27000,
+	.clock = 28341,
 	.hdisplay = 480,
 	.hsync_start = 480 + 10,
 	.hsync_end = 480 + 10 + 59,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/33] drm/panel-sitronix-st7789v: Fix dotclock

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index cc02c54c1b2e..5e9d706d06a6 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -156,7 +156,7 @@ static int st7789v_write_data(struct st7789v *ctx, u8 cmd)
 }
 
 static const struct drm_display_mode default_mode = {
-	.clock = 7000,
+	.clock = 6008,
 	.hdisplay = 240,
 	.hsync_start = 240 + 38,
 	.hsync_end = 240 + 38 + 10,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-sony-acx424akp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
index de0abf76ae6f..c91e55b2d7a3 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx424akp.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
@@ -48,7 +48,7 @@ struct acx424akp {
 };
 
 static const struct drm_display_mode sony_acx424akp_vid_mode = {
-	.clock = 330000,
+	.clock = 27234,
 	.hdisplay = 480,
 	.hsync_start = 480 + 15,
 	.hsync_end = 480 + 15 + 0,
@@ -68,7 +68,7 @@ static const struct drm_display_mode sony_acx424akp_vid_mode = {
  * command mode using the maximum HS frequency.
  */
 static const struct drm_display_mode sony_acx424akp_cmd_mode = {
-	.clock = 420160,
+	.clock = 35478,
 	.hdisplay = 480,
 	.hsync_start = 480 + 154,
 	.hsync_end = 480 + 154 + 16,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/33] drm/panel-simple: Fix dotclock for AUO G101EVN010

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Alex Gonzalez <alex.gonzalez@digi.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 342d075e80c5..9782a016a157 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -827,7 +827,7 @@ static const struct panel_desc auo_g070vvn01 = {
 };
 
 static const struct drm_display_mode auo_g101evn010_mode = {
-	.clock = 68930,
+	.clock = 70894,
 	.hdisplay = 1280,
 	.hsync_start = 1280 + 82,
 	.hsync_end = 1280 + 82 + 2,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Christoph Fritz <chf.fritz@googlemail.com>
Cc: Stefan Riedmueller <s.riedmueller@phytec.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9782a016a157..8643ba7e76a6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -851,7 +851,7 @@ static const struct panel_desc auo_g101evn010 = {
 };
 
 static const struct drm_display_mode auo_g104sn02_mode = {
-	.clock = 40000,
+	.clock = 45963,
 	.hdisplay = 800,
 	.hsync_start = 800 + 40,
 	.hsync_end = 800 + 40 + 216,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/33] drm/panel-simple: Fix dotclock for CDTech S043WQ26H-CT7

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 8643ba7e76a6..d2980485d0c5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1136,7 +1136,7 @@ static const struct panel_desc boe_nv140fhmn49 = {
 };
 
 static const struct drm_display_mode cdtech_s043wq26h_ct7_mode = {
-	.clock = 9000,
+	.clock = 9413,
 	.hdisplay = 480,
 	.hsync_start = 480 + 5,
 	.hsync_end = 480 + 5 + 5,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/33] drm/panel-simple: Fix dotclock for CDTech S070WV95-CT16

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index d2980485d0c5..9b19ffb23755 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1161,7 +1161,7 @@ static const struct panel_desc cdtech_s043wq26h_ct7 = {
 };
 
 static const struct drm_display_mode cdtech_s070wv95_ct16_mode = {
-	.clock = 35000,
+	.clock = 29232,
 	.hdisplay = 800,
 	.hsync_start = 800 + 40,
 	.hsync_end = 800 + 40 + 40,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 13/33] drm/panel-simple: Fix dotclock for Chunghwa CLAA070WP03XG

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Randy Li <ayaka@soulik.info>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9b19ffb23755..6ad38b6a3950 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1185,7 +1185,7 @@ static const struct panel_desc cdtech_s070wv95_ct16 = {
 };
 
 static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
-	.clock = 66770,
+	.clock = 70284,
 	.hdisplay = 800,
 	.hsync_start = 800 + 49,
 	.hsync_end = 800 + 49 + 33,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 14/33] drm/panel-simple: Fix dotclock for Chunghwa Picture Tubes 10.1" WXGA

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 6ad38b6a3950..93e5bc32fb59 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1232,7 +1232,7 @@ static const struct panel_desc chunghwa_claa101wa01a = {
 };
 
 static const struct drm_display_mode chunghwa_claa101wb01_mode = {
-	.clock = 69300,
+	.clock = 71072,
 	.hdisplay = 1366,
 	.hsync_start = 1366 + 48,
 	.hsync_end = 1366 + 48 + 32,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Andreas Pretzsch <apr@cn-eng.de>
Cc: Marco Felsch <m.felsch@pengutronix.de>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 93e5bc32fb59..35750229189f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1342,7 +1342,7 @@ static const struct panel_desc dlc_dlc1010gig = {
 };
 
 static const struct drm_display_mode edt_et035012dm6_mode = {
-	.clock = 6500,
+	.clock = 6414,
 	.hdisplay = 320,
 	.hsync_start = 320 + 20,
 	.hsync_end = 320 + 20 + 30,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 16/33] drm/panel-simple: Fix dotclock for EDT ET043080DH6-GP

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 35750229189f..357b8578a62f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1368,7 +1368,7 @@ static const struct panel_desc edt_et035012dm6 = {
 };
 
 static const struct drm_display_mode edt_etm043080dh6gp_mode = {
-	.clock = 10870,
+	.clock = 9722,
 	.hdisplay = 480,
 	.hsync_start = 480 + 8,
 	.hsync_end = 480 + 8 + 4,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 17/33] drm/panel-simple: Fix dotclock for Foxlink FL500WVR00-A0T

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 357b8578a62f..baccf407222c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1514,7 +1514,7 @@ static const struct panel_desc evervision_vgg804821 = {
 };
 
 static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
-	.clock = 32260,
+	.clock = 35414,
 	.hdisplay = 800,
 	.hsync_start = 800 + 168,
 	.hsync_end = 800 + 168 + 64,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 18/33] drm/panel-simple: Fix dotclock for Giantplus GPG482739QS5

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index baccf407222c..3e98dbfc31c4 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1588,7 +1588,7 @@ static const struct panel_desc friendlyarm_hd702e = {
 };
 
 static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
-	.clock = 9000,
+	.clock = 9121,
 	.hdisplay = 480,
 	.hsync_start = 480 + 5,
 	.hsync_end = 480 + 5 + 1,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 19/33] drm/panel-simple: Fix dotclock for Innolux AT070TN92

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Riccardo Bortolato <bortolato@navaltechitalia.it>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 3e98dbfc31c4..8daec89eed5c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1745,7 +1745,7 @@ static const struct panel_desc innolux_at043tn24 = {
 };
 
 static const struct drm_display_mode innolux_at070tn92_mode = {
-	.clock = 33333,
+	.clock = 34540,
 	.hdisplay = 800,
 	.hsync_start = 800 + 210,
 	.hsync_end = 800 + 210 + 20,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 20/33] drm/panel-simple: Fix dotclock for LeMaker BL035-RGB-002 3.5" LCD

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Paul Kocialkowski <contact@paulk.fr>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 8daec89eed5c..225be4757a85 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2065,7 +2065,7 @@ static const struct panel_desc kyo_tcg121xglp = {
 };
 
 static const struct drm_display_mode lemaker_bl035_rgb_002_mode = {
-	.clock = 7000,
+	.clock = 6414,
 	.hdisplay = 320,
 	.hsync_start = 320 + 20,
 	.hsync_end = 320 + 20 + 30,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Adam Ford <aford173@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 225be4757a85..3a46b82722f5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2277,7 +2277,7 @@ static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
 };
 
 static const struct drm_display_mode logicpd_type_28_mode = {
-	.clock = 9000,
+	.clock = 9107,
 	.hdisplay = 480,
 	.hsync_start = 480 + 3,
 	.hsync_end = 480 + 3 + 42,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 22/33] drm/panel-simple: Fix dotclock for Netron DY E231732

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 3a46b82722f5..0ac74c625f8e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2384,7 +2384,7 @@ static const struct panel_desc nec_nl4827hc19_05b = {
 };
 
 static const struct drm_display_mode netron_dy_e231732_mode = {
-	.clock = 66000,
+	.clock = 60480,
 	.hdisplay = 1024,
 	.hsync_start = 1024 + 160,
 	.hsync_end = 1024 + 160 + 70,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 23/33] drm/panel-simple: Fix dotclock for On Tat Industrial Company 7" DPI TFT

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 0ac74c625f8e..ca72b73408e9 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2588,7 +2588,7 @@ static const struct panel_desc olimex_lcd_olinuxino_43ts = {
  * installation instructions.
  */
 static const struct drm_display_mode ontat_yx700wv03_mode = {
-	.clock = 29500,
+	.clock = 29760,
 	.hdisplay = 800,
 	.hsync_start = 824,
 	.hsync_end = 896,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index ca72b73408e9..f9b4f84bffb3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2617,7 +2617,7 @@ static const struct panel_desc ontat_yx700wv03 = {
 };
 
 static const struct drm_display_mode ortustech_com37h3m_mode  = {
-	.clock = 22153,
+	.clock = 19842,
 	.hdisplay = 480,
 	.hsync_start = 480 + 8,
 	.hsync_end = 480 + 8 + 10,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 25/33] drm/panel-simple: Fix dotclock for PDA 91-00156-A0

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index f9b4f84bffb3..f02b510dabf7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2697,7 +2697,7 @@ static const struct panel_desc osddisplays_osd070t1718_19ts = {
 };
 
 static const struct drm_display_mode pda_91_00156_a0_mode = {
-	.clock = 33300,
+	.clock = 29319,
 	.hdisplay = 800,
 	.hsync_start = 800 + 1,
 	.hsync_end = 800 + 1 + 64,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 26/33] drm/panel-simple: Fix dotclock for QiaoDian qd43003c0-40

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Josh Wu <josh.wu@atmel.com>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index f02b510dabf7..3012b47c1e4e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2721,7 +2721,7 @@ static const struct panel_desc pda_91_00156_a0  = {
 
 
 static const struct drm_display_mode qd43003c0_40_mode = {
-	.clock = 9000,
+	.clock = 9176,
 	.hdisplay = 480,
 	.hsync_start = 480 + 8,
 	.hsync_end = 480 + 8 + 4,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 3012b47c1e4e..7526af2d6d95 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2949,7 +2949,7 @@ static const struct panel_desc sharp_lq070y3dg3b = {
 };
 
 static const struct drm_display_mode sharp_lq035q7db03_mode = {
-	.clock = 5500,
+	.clock = 5419,
 	.hdisplay = 240,
 	.hsync_start = 240 + 16,
 	.hsync_end = 240 + 16 + 7,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Gustaf Lindström <gl@axentia.se>
Cc: Peter Rosin <peda@axentia.se>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 7526af2d6d95..cb587de8c49e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3026,7 +3026,7 @@ static const struct panel_desc sharp_lq123p1jx31 = {
 };
 
 static const struct drm_display_mode sharp_lq150x1lg11_mode = {
-	.clock = 71100,
+	.clock = 65722,
 	.hdisplay = 1024,
 	.hsync_start = 1024 + 168,
 	.hsync_end = 1024 + 168 + 64,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 29/33] drm/panel-simple: Fix dotclock for Shelly SCA07010-BFN-LNN

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index cb587de8c49e..46a82ca5c2ca 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3077,7 +3077,7 @@ static const struct panel_desc sharp_ls020b1dd01d = {
 };
 
 static const struct drm_display_mode shelly_sca07010_bfn_lnn_mode = {
-	.clock = 33300,
+	.clock = 29319,
 	.hdisplay = 800,
 	.hsync_start = 800 + 1,
 	.hsync_end = 800 + 1 + 64,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 30/33] drm/panel-simple: Fix dotclock for TPK U.S.A. LLC Fusion

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 46a82ca5c2ca..5ce1328fd7dc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3309,7 +3309,7 @@ static const struct panel_desc tpk_f07a_0102 = {
 };
 
 static const struct drm_display_mode tpk_f10a_0102_mode = {
-	.clock = 45000,
+	.clock = 50427,
 	.hdisplay = 1024,
 	.hsync_start = 1024 + 176,
 	.hsync_end = 1024 + 176 + 5,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Fabio Estevam <festevam@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 5ce1328fd7dc..6b48c02af112 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3368,7 +3368,7 @@ static const struct panel_desc urt_umsh_8596md_parallel = {
 };
 
 static const struct drm_display_mode vl050_8048nt_c01_mode = {
-	.clock = 33333,
+	.clock = 34540,
 	.hdisplay = 800,
 	.hsync_start = 800 + 210,
 	.hsync_end = 800 + 210 + 20,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 32/33] drm/panel-simple: Fix dotclock for LG LH500WX1-SD03

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 6b48c02af112..b24fdf239440 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3939,7 +3939,7 @@ static const struct panel_desc_dsi lg_ld070wx3_sl01 = {
 };
 
 static const struct drm_display_mode lg_lh500wx1_sd03_mode = {
-	.clock = 67000,
+	.clock = 66348,
 	.hdisplay = 720,
 	.hsync_start = 720 + 12,
 	.hsync_end = 720 + 12 + 4,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Jonathan Marek <jonathan@marek.ca>
Cc: Brian Masney <masneyb@onstation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index b24fdf239440..f958d8dfd760 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 = {
 };
 
 static const struct drm_display_mode lg_acx467akm_7_mode = {
-	.clock = 150000,
+	.clock = 125498,
 	.hdisplay = 1080,
 	.hsync_start = 1080 + 2,
 	.hsync_end = 1080 + 2 + 2,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Jonathan Marek]

Hi,

This is a command mode panel and the the msm/mdp5 driver uses the 
vrefresh field for the actual refresh rate, while the dotclock field is 
used for the DSI clocks. The dotclock needed to be a bit higher than 
necessary otherwise the panel would not work.

If you want to get rid of the separate clock/vrefresh fields there would 
need to be some changes to msm driver.

(note I hadn't made the patch with upstreaming in mind, the 150000 value 
is likely not optimal, just something that worked, this is something 
that should have been checked with the downstream driver)

-Jonathan

On 3/2/20 3:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
> 
> Cc: Jonathan Marek <jonathan@marek.ca>
> Cc: Brian Masney <masneyb@onstation.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>   drivers/gpu/drm/panel/panel-simple.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index b24fdf239440..f958d8dfd760 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 = {
>   };
>   
>   static const struct drm_display_mode lg_acx467akm_7_mode = {
> -	.clock = 150000,
> +	.clock = 125498,
>   	.hdisplay = 1080,
>   	.hsync_start = 1080 + 2,
>   	.hsync_end = 1080 + 2 + 2,
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

[H. Nikolaus Schaller]

Hi Ville,

> Am 02.03.2020 um 21:34 schrieb Ville Syrjala <ville.syrjala@linux.intel.com>:
> 
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?

Data sheet of COM37H3M99DTC says:

			MIN	TYP	MAX
CLK frequency 	fCLK	18	19.8	27	MHz
VSYNC Frequency	fVSYNC	54	60	66	Hz
VSYNC cycle time tv	646	650	700	H
HSYNC frequency	fHSYNC	--	39.0	50.0	Khz
HSYNC cycle time th	504	508	630	CLK

But data sheet of COM37H3M05DTC says

			MIN	TYP	MAX
CLK frequency 	fCLK	--	22.4	26.3	MHz (in VGA mode - there is also an QVGA mode)
VSYNC Frequency	fVSYNC	54	60	66	Hz
VSYNC cycle time tv	--	650	--	H
HSYNC frequency	fHSYNC	--	39.3	--	Khz
HSYNC cycle time th	--	570	--	CLK

So there are two different subvariants of the same panel.

If I remember correctly, the 05 is older (April 2010)
and the 99DTC newer (Dec 2011).

So 22 MHz isn't outside of either spec but may be higher
than needed for the 99DTC. I.e. the panel is probably
running at higher frame rate than 60 fps.

Hm. I think we should define some compromise. I.e.

.clock = 22230
.vrefresh = 60
.vtotal = 650
.htotal = 570

Probably we originally tried to do this with the parameter
set but got something wrong.

If you agree with this approach, I can try to figure out
the other parameters so that they should fit both panel
variants. I can only test with COM37H3M99DTC since I
do no longer have a device with COM37H3M05DTC.

In general it seems that the structure drm_display_mode
is overdetermined.

Either .clock could be calculated from .vrefresh (and
the other .vtotal and .htotal) or vice versa like I
did for the proposal above.

I haven't looked into the driver code, but would it be
possible to specify .clock = 0 (or leave it out) to
calculate it bottom up? This would avoid such inconsistencies.

On the other hand it is not easily visible any more
from the code if the clock is in range of the data
sheet limits.

BR and thanks,
Nikolaus

> 
> Cc: H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index ca72b73408e9..f9b4f84bffb3 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2617,7 +2617,7 @@ static const struct panel_desc ontat_yx700wv03 = {
> };
> 
> static const struct drm_display_mode ortustech_com37h3m_mode  = {
> -	.clock = 22153,
> +	.clock = 19842,
> 	.hdisplay = 480,
> 	.hsync_start = 480 + 8,
> 	.hsync_end = 480 + 8 + 10,
> -- 
> 2.24.1
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03

[Vladimir Zapolskiy]

Hi Ville,

On 3/2/20 10:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?

yes, I will tell you, see my answer below.

Adding Linus as a person who may be interested in PL111 specifics.

> Cc: Vladimir Zapolskiy <vz@mleia.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 3012b47c1e4e..7526af2d6d95 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2949,7 +2949,7 @@ static const struct panel_desc sharp_lq070y3dg3b = {
>  };
>  
>  static const struct drm_display_mode sharp_lq035q7db03_mode = {
> -	.clock = 5500,
> +	.clock = 5419,
>  	.hdisplay = 240,
>  	.hsync_start = 240 + 16,
>  	.hsync_end = 240 + 16 + 7,
> 

Here .clock is correct, you may find the usage of the panel in
lpc3250-phy3250.dts example, and the PL111 controller on the SoC
won't be able to provide the exactly computed `.clock = 5419'.

So, I have to NAK this change, in this example the difference
between the declared and the computed .vreresh is one Hz, which
I hope can be accepted as negligible and ignorable, otherwise,
if you insist, please correct the .vrefresh from 60 to 61.

--
Best wishes,
Vladimir
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/33] drm/panel: Fix dotclocks

[Sam Ravnborg]

Hi Ville.

On Mon, Mar 02, 2020 at 10:34:19PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> A lot of the panel drivers put bogus looking values into
> mode.clock. This series replaces the bogus values with
> mode.vrefresh*mode.htotal*mode.vtotal.

I think you got it wrong....
The few I sampled I would rather say that the clock
specified was the one that was possible with the present
HW and the refresh rate was then set to what was attempted.

Example:
chunghwa_claa101wb01_mode

clock is 69300 - which looks like a value you could configure
in HW. It not not a nive round value.
refresh is 60, which looks like the refresh value that was attempted.

So unless there is a big difference between the
calcualted refresh (based on the specifed clock),
and the specified clock it should be assumed that clock is OK.
And it is OK to drop refresh.

This is my take on it - but you based your patches on refresh.
So maybe you have a better rationale to do so?

Also, let's await feedback from the people cc'ed on the pathces.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

[Peter Rosin]

On 2020-03-02 21:34, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?

TL/DR; I do not care if you change the refresh rate or the dotclock.

The whole entry for that panel in simple-panel is dubious. The panel
is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
with the SELLVDS pin).  With Jeida you can, as usual, omit the 4th
data channel and use the panel with RGB666. In either case, you need
an LVDS signal and nothing else...

The panel can also rotate the picture 180 degrees using the RL/UD pin.

These options are of course not expressed in the simple panel driver
(and we have always used fixed signals for those pins in our designs,
IIRC). As far as I'm concerned, the panel can be removed from
simple-panel. Our device trees are nowadays correctly expressing the
hardware with an LVDS encoder between the RGB output and the panel
and points to the panel-lvds driver for the panel.

The reason that it is as it is, is that we obviously didn't understand
what we were doing when we added the entry, and this garbage was what
we came up with that produced a picture.

If you want to keep the panel in simple-panel despite all this, the
timing constraints are as follows:

Pixel clock         50-80 MHz,        65 MHz typical
Horizontal period 1094-1720 clocks, 1344 typical
                  16.0-23.4 us      20.7 us
Horizontal enable    1024 clocks, always
Vertical period    776-990 lines,    806 typical
                  13.3-18.0 ms      16.7 ms
Vertical enable       768 lines,  always

Using a "long" (the datasheet is not very specific on this issue) vertical
period may introduce deterioration of display quality, flicker etc.

I don't think the division between front-porch/back-porch matters much.

That said, I have no idea whatsoever if others have started using this
panel entry. My guess is that it has zero users, but who can tell?

Cheers,
Peter

> Cc: Gustaf Lindström <gl@axentia.se>
> Cc: Peter Rosin <peda@axentia.se>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 7526af2d6d95..cb587de8c49e 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3026,7 +3026,7 @@ static const struct panel_desc sharp_lq123p1jx31 = {
>  };
>  
>  static const struct drm_display_mode sharp_lq150x1lg11_mode = {
> -	.clock = 71100,
> +	.clock = 65722,
>  	.hdisplay = 1024,
>  	.hsync_start = 1024 + 168,
>  	.hsync_end = 1024 + 168 + 64,
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock

[Icenowy Zheng]

于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala <ville.syrjala@linux.intel.com> 写到:
>From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
>The currently listed dotclock disagrees with the currently
>listed vrefresh rate. Change the dotclock to match the vrefresh.
>
>Someone tell me which (if either) of the dotclock or vreresh is
>correct?

dotclock is correct and vrefresh is only a placeholder value.

>
>Cc: Icenowy Zheng <icenowy@aosc.io>
>Cc: Sam Ravnborg <sam@ravnborg.org>
>Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>index fddbfddf6566..8debee85f4ec 100644
>--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel
>*panel)
> }
> 
> static const struct drm_display_mode k101_im2ba02_default_mode = {
>-	.clock = 70000,
>+	.clock = 67286,
> 	.vrefresh = 60,
> 
> 	.hdisplay = 800,

-- 
使用 K-9 Mail 发送自我的Android设备。
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Brian Masney]

On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> Hi,
> 
> This is a command mode panel and the the msm/mdp5 driver uses the vrefresh
> field for the actual refresh rate, while the dotclock field is used for the
> DSI clocks. The dotclock needed to be a bit higher than necessary otherwise
> the panel would not work.
> 
> If you want to get rid of the separate clock/vrefresh fields there would
> need to be some changes to msm driver.
> 
> (note I hadn't made the patch with upstreaming in mind, the 150000 value is
> likely not optimal, just something that worked, this is something that
> should have been checked with the downstream driver)

Is this the right clock frequency in the downstream MSM 3.4 kernel that
you're talking about?

https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326

I don't see any obvious clock values in the downstream command mode
panel configuration: 

https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591

Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
and everything appears to be working fine. You can add my Tested-by if
you end up applying this.

Tested-by: Brian Masney <masneyb@onstation.org>

Brian


> On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > 
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> > 
> > Cc: Jonathan Marek <jonathan@marek.ca>
> > Cc: Brian Masney <masneyb@onstation.org>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >   drivers/gpu/drm/panel/panel-simple.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index b24fdf239440..f958d8dfd760 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 = {
> >   };
> >   static const struct drm_display_mode lg_acx467akm_7_mode = {
> > -	.clock = 150000,
> > +	.clock = 125498,
> >   	.hdisplay = 1080,
> >   	.hsync_start = 1080 + 2,
> >   	.hsync_end = 1080 + 2 + 2,
> > 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Jonathan Marek]

On 3/2/20 10:13 PM, Brian Masney wrote:
> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>> Hi,
>>
>> This is a command mode panel and the the msm/mdp5 driver uses the vrefresh
>> field for the actual refresh rate, while the dotclock field is used for the
>> DSI clocks. The dotclock needed to be a bit higher than necessary otherwise
>> the panel would not work.
>>
>> If you want to get rid of the separate clock/vrefresh fields there would
>> need to be some changes to msm driver.
>>
>> (note I hadn't made the patch with upstreaming in mind, the 150000 value is
>> likely not optimal, just something that worked, this is something that
>> should have been checked with the downstream driver)
> 
> Is this the right clock frequency in the downstream MSM 3.4 kernel that
> you're talking about?
> 
> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> 

No, I'm talking about the DSI clock (the driver for it is in 
drm/msm/dsi/). For a command mode panel the front/back porches aren't 
relevant, but the dsi pixel/byte clock need to be a bit higher than 
1920x1080x60. Since 125498 is a little higher than 124416 that might be 
enough (there is also rounding of the clock values to consider).

> I don't see any obvious clock values in the downstream command mode
> panel configuration:
> 
> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> 
> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> and everything appears to be working fine. You can add my Tested-by if
> you end up applying this.
> 
> Tested-by: Brian Masney <masneyb@onstation.org>
> 
> Brian
> 
> 
>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> The currently listed dotclock disagrees with the currently
>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>
>>> Someone tell me which (if either) of the dotclock or vreresh is
>>> correct?
>>>
>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>> Cc: Brian Masney <masneyb@onstation.org>
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> ---
>>>    drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
>>> index b24fdf239440..f958d8dfd760 100644
>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 = {
>>>    };
>>>    static const struct drm_display_mode lg_acx467akm_7_mode = {
>>> -	.clock = 150000,
>>> +	.clock = 125498,
>>>    	.hdisplay = 1080,
>>>    	.hsync_start = 1080 + 2,
>>>    	.hsync_end = 1080 + 2 + 2,
>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Jonathan Marek]

Another thing: did you verify that the panel still runs at 60hz (and not 
dropping frames to 30hz)? IIRC that was the behavior with lower clock.

On 3/2/20 10:28 PM, Jonathan Marek wrote:
> 
> On 3/2/20 10:13 PM, Brian Masney wrote:
>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>> Hi,
>>>
>>> This is a command mode panel and the the msm/mdp5 driver uses the 
>>> vrefresh
>>> field for the actual refresh rate, while the dotclock field is used 
>>> for the
>>> DSI clocks. The dotclock needed to be a bit higher than necessary 
>>> otherwise
>>> the panel would not work.
>>>
>>> If you want to get rid of the separate clock/vrefresh fields there would
>>> need to be some changes to msm driver.
>>>
>>> (note I hadn't made the patch with upstreaming in mind, the 150000 
>>> value is
>>> likely not optimal, just something that worked, this is something that
>>> should have been checked with the downstream driver)
>>
>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>> you're talking about?
>>
>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326 
>>
>>
> 
> No, I'm talking about the DSI clock (the driver for it is in 
> drm/msm/dsi/). For a command mode panel the front/back porches aren't 
> relevant, but the dsi pixel/byte clock need to be a bit higher than 
> 1920x1080x60. Since 125498 is a little higher than 124416 that might be 
> enough (there is also rounding of the clock values to consider).
> 
>> I don't see any obvious clock values in the downstream command mode
>> panel configuration:
>>
>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591 
>>
>>
>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>> and everything appears to be working fine. You can add my Tested-by if
>> you end up applying this.
>>
>> Tested-by: Brian Masney <masneyb@onstation.org>
>>
>> Brian
>>
>>
>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>
>>>> The currently listed dotclock disagrees with the currently
>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>
>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>> correct?
>>>>
>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>> ---
>>>>    drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>> index b24fdf239440..f958d8dfd760 100644
>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi 
>>>> panasonic_vvx10f004b00 = {
>>>>    };
>>>>    static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>> -    .clock = 150000,
>>>> +    .clock = 125498,
>>>>        .hdisplay = 1080,
>>>>        .hsync_start = 1080 + 2,
>>>>        .hsync_end = 1080 + 2 + 2,
>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/33] drm/panel-lg-lg4573: Fix dotclock

[Heiko Schocher]

Hello Ville Syrjala,

Am 02.03.2020 um 21:34 schrieb Ville Syrjala:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?

Your clock fix is correct, thanks!

> 
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>   drivers/gpu/drm/panel/panel-lg-lg4573.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Heiko Schocher <hs@denx.de>

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs@denx.de
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6

[Marco Felsch]

Hi Ville,

On 20-03-02 22:34, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?

Pls, check the datasheet which is linked within the comment. We hit the
vrefresh exactly if we are in SYNC MODE.

Regards,
  Marco

> Cc: Andreas Pretzsch <apr@cn-eng.de>
> Cc: Marco Felsch <m.felsch@pengutronix.de>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 93e5bc32fb59..35750229189f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1342,7 +1342,7 @@ static const struct panel_desc dlc_dlc1010gig = {
>  };
>  
>  static const struct drm_display_mode edt_et035012dm6_mode = {
> -	.clock = 6500,
> +	.clock = 6414,
>  	.hdisplay = 320,
>  	.hsync_start = 320 + 20,
>  	.hsync_end = 320 + 20 + 30,
> -- 
> 2.24.1
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/33] drm/panel-arm-versatile: Fix dotclock

[Linus Walleij]

On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:

> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?

I actually answered this in the mail thread where refresh was
deleted:

These dotclocks are correct. Delete the incorrect vrefresh instead.

So please drop this patch.

Thanks,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Brian Masney]

On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> Another thing: did you verify that the panel still runs at 60hz (and not
> dropping frames to 30hz)? IIRC that was the behavior with lower clock.

Yes, the panel is running at 60 HZ according to the Xorg log with
Ville's patch applied:

    modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
    1920 1922 1924 1926 (115.6 kHz eP)

I verified there's no underflow errors in dmesg.

If I recall correctly, the clock speeds that was in your tree was set
too low for the gpu_opp_table (that wouldn't cause this issue), but I
seem to recall there were some other clock speed mismatches. The
bandwidth requests weren't set on the RPM as well, so maybe that
contributed to the problem. That's done upstream with the msm8974
interconnect driver:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c

There's a separate known issue with 'pp done time out' errors that
occur on the framebuffer that started upstream several months ago with
the introduction of async commit support in the MSM driver. I tried
working around this by enabling the autorefresh feature but it's not
fully working yet and I hit a dead end since there's no docs available
publicly for this. The grim details are at:

https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/

So I'm still OK with Ville's patch going in.

Brian


> 
> On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > 
> > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > Hi,
> > > > 
> > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > the vrefresh
> > > > field for the actual refresh rate, while the dotclock field is
> > > > used for the
> > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > necessary otherwise
> > > > the panel would not work.
> > > > 
> > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > need to be some changes to msm driver.
> > > > 
> > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > 150000 value is
> > > > likely not optimal, just something that worked, this is something that
> > > > should have been checked with the downstream driver)
> > > 
> > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > you're talking about?
> > > 
> > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > 
> > > 
> > 
> > No, I'm talking about the DSI clock (the driver for it is in
> > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > enough (there is also rounding of the clock values to consider).
> > 
> > > I don't see any obvious clock values in the downstream command mode
> > > panel configuration:
> > > 
> > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > 
> > > 
> > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > and everything appears to be working fine. You can add my Tested-by if
> > > you end up applying this.
> > > 
> > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > 
> > > Brian
> > > 
> > > 
> > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > 
> > > > > The currently listed dotclock disagrees with the currently
> > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > 
> > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > correct?
> > > > > 
> > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > ---
> > > > >    drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > panasonic_vvx10f004b00 = {
> > > > >    };
> > > > >    static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > -    .clock = 150000,
> > > > > +    .clock = 125498,
> > > > >        .hdisplay = 1080,
> > > > >        .hsync_start = 1080 + 2,
> > > > >        .hsync_end = 1080 + 2 + 2,
> > > > > 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock

[Heiko Stuebner]

Hi,

Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?

The values came that way from the vendor .
And lookin at other Leadtek display datasheets, 60Hz should be the
correct refresh rate.

The display is also running happily at the 69MHz of
your patch, so

Tested-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>


Heiko

> 
> Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> index 76ecf2de9c44..113ab9c0396b 100644
> --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
>  	.vsync_end	= 1280 + 30 + 4,
>  	.vtotal		= 1280 + 30 + 4 + 12,
>  	.vrefresh	= 60,
> -	.clock		= 41600,
> +	.clock		= 69217,
>  	.width_mm	= 62,
>  	.height_mm	= 110,
>  };
> 




_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28

[Adam Ford]

On Mon, Mar 2, 2020 at 2:36 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 225be4757a85..3a46b82722f5 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2277,7 +2277,7 @@ static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
>  };
>
>  static const struct drm_display_mode logicpd_type_28_mode = {
> -       .clock = 9000,
> +       .clock = 9107,

This should be OK.  The max dotclk frequency of this panel is 12MHz,
so 9.107MHz should be just fine.

Reviewed-by: Adam Ford <aford173@gmail.com>

adam
>         .hdisplay = 480,
>         .hsync_start = 480 + 3,
>         .hsync_end = 480 + 3 + 42,
> --
> 2.24.1
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Jonathan Marek]

What Xorg prints doesn't mean anything. I don't think there will be 
errors in dmesg, you need to run something that does pageflips as fast 
as possible and see that the refresh rate is still 60. (modetest with 
-v, glmark-drm are examples)

On 3/3/20 7:26 AM, Brian Masney wrote:
> On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
>> Another thing: did you verify that the panel still runs at 60hz (and not
>> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> 
> Yes, the panel is running at 60 HZ according to the Xorg log with
> Ville's patch applied:
> 
>      modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
>      1920 1922 1924 1926 (115.6 kHz eP)
> 
> I verified there's no underflow errors in dmesg.
> 
> If I recall correctly, the clock speeds that was in your tree was set
> too low for the gpu_opp_table (that wouldn't cause this issue), but I
> seem to recall there were some other clock speed mismatches. The
> bandwidth requests weren't set on the RPM as well, so maybe that
> contributed to the problem. That's done upstream with the msm8974
> interconnect driver:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> 
> There's a separate known issue with 'pp done time out' errors that
> occur on the framebuffer that started upstream several months ago with
> the introduction of async commit support in the MSM driver. I tried
> working around this by enabling the autorefresh feature but it's not
> fully working yet and I hit a dead end since there's no docs available
> publicly for this. The grim details are at:
> 
> https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> 
> So I'm still OK with Ville's patch going in.
> 
> Brian
> 
> 
>>
>> On 3/2/20 10:28 PM, Jonathan Marek wrote:
>>>
>>> On 3/2/20 10:13 PM, Brian Masney wrote:
>>>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>>>> Hi,
>>>>>
>>>>> This is a command mode panel and the the msm/mdp5 driver uses
>>>>> the vrefresh
>>>>> field for the actual refresh rate, while the dotclock field is
>>>>> used for the
>>>>> DSI clocks. The dotclock needed to be a bit higher than
>>>>> necessary otherwise
>>>>> the panel would not work.
>>>>>
>>>>> If you want to get rid of the separate clock/vrefresh fields there would
>>>>> need to be some changes to msm driver.
>>>>>
>>>>> (note I hadn't made the patch with upstreaming in mind, the
>>>>> 150000 value is
>>>>> likely not optimal, just something that worked, this is something that
>>>>> should have been checked with the downstream driver)
>>>>
>>>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>>>> you're talking about?
>>>>
>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>>>>
>>>>
>>>
>>> No, I'm talking about the DSI clock (the driver for it is in
>>> drm/msm/dsi/). For a command mode panel the front/back porches aren't
>>> relevant, but the dsi pixel/byte clock need to be a bit higher than
>>> 1920x1080x60. Since 125498 is a little higher than 124416 that might be
>>> enough (there is also rounding of the clock values to consider).
>>>
>>>> I don't see any obvious clock values in the downstream command mode
>>>> panel configuration:
>>>>
>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>>>>
>>>>
>>>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>>>> and everything appears to be working fine. You can add my Tested-by if
>>>> you end up applying this.
>>>>
>>>> Tested-by: Brian Masney <masneyb@onstation.org>
>>>>
>>>> Brian
>>>>
>>>>
>>>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>
>>>>>> The currently listed dotclock disagrees with the currently
>>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>>
>>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>>> correct?
>>>>>>
>>>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>>>> index b24fdf239440..f958d8dfd760 100644
>>>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
>>>>>> panasonic_vvx10f004b00 = {
>>>>>>     };
>>>>>>     static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>>>> -    .clock = 150000,
>>>>>> +    .clock = 125498,
>>>>>>         .hdisplay = 1080,
>>>>>>         .hsync_start = 1080 + 2,
>>>>>>         .hsync_end = 1080 + 2 + 2,
>>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2

[Christoph Fritz]

On Mon, 2020-03-02 at 22:34 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
> 
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?

This display (a controller is included) has a wide tolerance range.

Adapting clock should be fine while keeping vrefresh rate at 60 Hz.

I guess an even better alternative would be to change this config to a
pixelclock describing one like the other auo panels.

But at the moment I'm not having a display here.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2727 bytes --]

On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
> On 2020-03-02 21:34, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > 
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> 
> TL/DR; I do not care if you change the refresh rate or the dotclock.
> 
> The whole entry for that panel in simple-panel is dubious. The panel
> is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
> with the SELLVDS pin).  With Jeida you can, as usual, omit the 4th
> data channel and use the panel with RGB666. In either case, you need
> an LVDS signal and nothing else...
> 
> The panel can also rotate the picture 180 degrees using the RL/UD pin.
> 
> These options are of course not expressed in the simple panel driver
> (and we have always used fixed signals for those pins in our designs,
> IIRC). As far as I'm concerned, the panel can be removed from
> simple-panel. Our device trees are nowadays correctly expressing the
> hardware with an LVDS encoder between the RGB output and the panel
> and points to the panel-lvds driver for the panel.

How do you make sure that you always bind against the correct driver? If
it matches simple-panel and panel-lvds, it's not deterministically going
to pick the right one. Well, it may actually be deterministic on Linux,
but perhaps only by accident.

> The reason that it is as it is, is that we obviously didn't understand
> what we were doing when we added the entry, and this garbage was what
> we came up with that produced a picture.
> 
> If you want to keep the panel in simple-panel despite all this, the
> timing constraints are as follows:
> 
> Pixel clock         50-80 MHz,        65 MHz typical
> Horizontal period 1094-1720 clocks, 1344 typical
>                   16.0-23.4 us      20.7 us
> Horizontal enable    1024 clocks, always
> Vertical period    776-990 lines,    806 typical
>                   13.3-18.0 ms      16.7 ms
> Vertical enable       768 lines,  always
> 
> Using a "long" (the datasheet is not very specific on this issue) vertical
> period may introduce deterioration of display quality, flicker etc.
> 
> I don't think the division between front-porch/back-porch matters much.
> 
> That said, I have no idea whatsoever if others have started using this
> panel entry. My guess is that it has zero users, but who can tell?

A quick grep shows that arch/arm/boot/dts/at91-nattis-2-natte-2.dts is
the only device tree that uses this panel in the upstream kernel.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03

[Ville Syrjälä]

On Mon, Mar 02, 2020 at 11:40:07PM +0200, Vladimir Zapolskiy wrote:
> Hi Ville,
> 
> On 3/2/20 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > 
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> 
> yes, I will tell you, see my answer below.
> 
> Adding Linus as a person who may be interested in PL111 specifics.
> 
> > Cc: Vladimir Zapolskiy <vz@mleia.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index 3012b47c1e4e..7526af2d6d95 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2949,7 +2949,7 @@ static const struct panel_desc sharp_lq070y3dg3b = {
> >  };
> >  
> >  static const struct drm_display_mode sharp_lq035q7db03_mode = {
> > -	.clock = 5500,
> > +	.clock = 5419,
> >  	.hdisplay = 240,
> >  	.hsync_start = 240 + 16,
> >  	.hsync_end = 240 + 16 + 7,
> > 
> 
> Here .clock is correct, you may find the usage of the panel in
> lpc3250-phy3250.dts example, and the PL111 controller on the SoC
> won't be able to provide the exactly computed `.clock = 5419'.

OK, I'll drop this one.

> 
> So, I have to NAK this change, in this example the difference
> between the declared and the computed .vreresh is one Hz, which
> I hope can be accepted as negligible and ignorable, otherwise,
> if you insist, please correct the .vrefresh from 60 to 61.

I'm going to nuke .vrefresh entirely.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/33] drm/panel: Fix dotclocks

[Ville Syrjälä]

On Mon, Mar 02, 2020 at 10:47:13PM +0100, Sam Ravnborg wrote:
> Hi Ville.
> 
> On Mon, Mar 02, 2020 at 10:34:19PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > A lot of the panel drivers put bogus looking values into
> > mode.clock. This series replaces the bogus values with
> > mode.vrefresh*mode.htotal*mode.vtotal.
> 
> I think you got it wrong....
> The few I sampled I would rather say that the clock
> specified was the one that was possible with the present
> HW and the refresh rate was then set to what was attempted.
> 
> Example:
> chunghwa_claa101wb01_mode
> 
> clock is 69300 - which looks like a value you could configure
> in HW. It not not a nive round value.
> refresh is 60, which looks like the refresh value that was attempted.
> 
> So unless there is a big difference between the
> calcualted refresh (based on the specifed clock),
> and the specified clock it should be assumed that clock is OK.
> And it is OK to drop refresh.
> 
> This is my take on it - but you based your patches on refresh.
> So maybe you have a better rationale to do so?

No. I just blindly converted everything and posted the patches
so people can tell me which way to go.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock

[Ville Syrjälä]

On Tue, Mar 03, 2020 at 07:36:35AM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala <ville.syrjala@linux.intel.com> 写到:
> >From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> >The currently listed dotclock disagrees with the currently
> >listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> >Someone tell me which (if either) of the dotclock or vreresh is
> >correct?
> 
> dotclock is correct and vrefresh is only a placeholder value.

Thanks. I'll drop this one.

> 
> >
> >Cc: Icenowy Zheng <icenowy@aosc.io>
> >Cc: Sam Ravnborg <sam@ravnborg.org>
> >Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >---
> > drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> >b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> >index fddbfddf6566..8debee85f4ec 100644
> >--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> >+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> >@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel
> >*panel)
> > }
> > 
> > static const struct drm_display_mode k101_im2ba02_default_mode = {
> >-	.clock = 70000,
> >+	.clock = 67286,
> > 	.vrefresh = 60,
> > 
> > 	.hdisplay = 800,
> 
> -- 
> 使用 K-9 Mail 发送自我的Android设备。

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6

[Ville Syrjälä]

On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> Hi Ville,
> 
> On 20-03-02 22:34, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > 
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> 
> Pls, check the datasheet which is linked within the comment. We hit the
> vrefresh exactly if we are in SYNC MODE.

It's too much work to start hunting datasheets for all these
and figuring out what's going on in each case. Pls just
inform me which way is correct if you know the details.

> 
> Regards,
>   Marco
> 
> > Cc: Andreas Pretzsch <apr@cn-eng.de>
> > Cc: Marco Felsch <m.felsch@pengutronix.de>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index 93e5bc32fb59..35750229189f 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1342,7 +1342,7 @@ static const struct panel_desc dlc_dlc1010gig = {
> >  };
> >  
> >  static const struct drm_display_mode edt_et035012dm6_mode = {
> > -	.clock = 6500,
> > +	.clock = 6414,
> >  	.hdisplay = 320,
> >  	.hsync_start = 320 + 20,
> >  	.hsync_end = 320 + 20 + 30,
> > -- 
> > 2.24.1
> > 
> > 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/33] drm/panel-arm-versatile: Fix dotclock

[Ville Syrjälä]

On Tue, Mar 03, 2020 at 01:10:26PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclocks disagree with the currently
> > listed vrefresh rates. Change the dotclocks to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> 
> I actually answered this in the mail thread where refresh was
> deleted:

Sorry for the dupe. The thread turned into a mess so I just
decided to start from a clean slate.

> 
> These dotclocks are correct. Delete the incorrect vrefresh instead.
> 
> So please drop this patch.

Will do. Thanks.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

[Peter Rosin]

On 2020-03-03 15:20, Thierry Reding wrote:
> On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
>> On 2020-03-02 21:34, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> The currently listed dotclock disagrees with the currently
>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>
>>> Someone tell me which (if either) of the dotclock or vreresh is
>>> correct?
>>
>> TL/DR; I do not care if you change the refresh rate or the dotclock.
>>
>> The whole entry for that panel in simple-panel is dubious. The panel
>> is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
>> with the SELLVDS pin).  With Jeida you can, as usual, omit the 4th
>> data channel and use the panel with RGB666. In either case, you need
>> an LVDS signal and nothing else...
>>
>> The panel can also rotate the picture 180 degrees using the RL/UD pin.
>>
>> These options are of course not expressed in the simple panel driver
>> (and we have always used fixed signals for those pins in our designs,
>> IIRC). As far as I'm concerned, the panel can be removed from
>> simple-panel. Our device trees are nowadays correctly expressing the
>> hardware with an LVDS encoder between the RGB output and the panel
>> and points to the panel-lvds driver for the panel.
> 
> How do you make sure that you always bind against the correct driver? If
> it matches simple-panel and panel-lvds, it's not deterministically going
> to pick the right one. Well, it may actually be deterministic on Linux,
> but perhaps only by accident.

You are probably right that it's fragile, but no problems so far. That
said, I did wonder why the panel-lvds driver "wins" over simple-panel for

	compatible = "sharp,lq150x1lg11", "panel-lvds";

I figured it was by design and didn't spend too much time thinking about
it. Maybe I should have?

>> The reason that it is as it is, is that we obviously didn't understand
>> what we were doing when we added the entry, and this garbage was what
>> we came up with that produced a picture.
>>
>> If you want to keep the panel in simple-panel despite all this, the
>> timing constraints are as follows:
>>
>> Pixel clock         50-80 MHz,        65 MHz typical
>> Horizontal period 1094-1720 clocks, 1344 typical
>>                   16.0-23.4 us      20.7 us
>> Horizontal enable    1024 clocks, always
>> Vertical period    776-990 lines,    806 typical
>>                   13.3-18.0 ms      16.7 ms
>> Vertical enable       768 lines,  always
>>
>> Using a "long" (the datasheet is not very specific on this issue) vertical
>> period may introduce deterioration of display quality, flicker etc.
>>
>> I don't think the division between front-porch/back-porch matters much.
>>
>> That said, I have no idea whatsoever if others have started using this
>> panel entry. My guess is that it has zero users, but who can tell?
> 
> A quick grep shows that arch/arm/boot/dts/at91-nattis-2-natte-2.dts is
> the only device tree that uses this panel in the upstream kernel.

This is our design, and what made us originally add the entry to simple
panel, but as I said, we no longer need simple-panel support for it...

Cheers,
Peter
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

[Ville Syrjälä]

On Mon, Mar 02, 2020 at 10:24:14PM +0100, H. Nikolaus Schaller wrote:
> Hi Ville,
> 
> > Am 02.03.2020 um 21:34 schrieb Ville Syrjala <ville.syrjala@linux.intel.com>:
> > 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > 
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> 
> Data sheet of COM37H3M99DTC says:
> 
> 			MIN	TYP	MAX
> CLK frequency 	fCLK	18	19.8	27	MHz
> VSYNC Frequency	fVSYNC	54	60	66	Hz
> VSYNC cycle time tv	646	650	700	H
> HSYNC frequency	fHSYNC	--	39.0	50.0	Khz
> HSYNC cycle time th	504	508	630	CLK
> 
> But data sheet of COM37H3M05DTC says
> 
> 			MIN	TYP	MAX
> CLK frequency 	fCLK	--	22.4	26.3	MHz (in VGA mode - there is also an QVGA mode)
> VSYNC Frequency	fVSYNC	54	60	66	Hz
> VSYNC cycle time tv	--	650	--	H
> HSYNC frequency	fHSYNC	--	39.3	--	Khz
> HSYNC cycle time th	--	570	--	CLK
> 
> So there are two different subvariants of the same panel.
> 
> If I remember correctly, the 05 is older (April 2010)
> and the 99DTC newer (Dec 2011).
> 
> So 22 MHz isn't outside of either spec but may be higher
> than needed for the 99DTC. I.e. the panel is probably
> running at higher frame rate than 60 fps.
> 
> Hm. I think we should define some compromise. I.e.
> 
> .clock = 22230
> .vrefresh = 60
> .vtotal = 650
> .htotal = 570
> 
> Probably we originally tried to do this with the parameter
> set but got something wrong.
> 
> If you agree with this approach, I can try to figure out
> the other parameters so that they should fit both panel
> variants. I can only test with COM37H3M99DTC since I
> do no longer have a device with COM37H3M05DTC.
> 
> In general it seems that the structure drm_display_mode
> is overdetermined.
> 
> Either .clock could be calculated from .vrefresh (and
> the other .vtotal and .htotal) or vice versa like I
> did for the proposal above.
> 
> I haven't looked into the driver code, but would it be
> possible to specify .clock = 0 (or leave it out) to
> calculate it bottom up? This would avoid such inconsistencies.

I'm going to remove .vrefresh entirely from the struct.
It'll just be calculated from the other timings as needed.

> 
> On the other hand it is not easily visible any more
> from the code if the clock is in range of the data
> sheet limits.
> 
> BR and thanks,
> Nikolaus
> 
> > 
> > Cc: H. Nikolaus Schaller <hns@goldelico.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index ca72b73408e9..f9b4f84bffb3 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2617,7 +2617,7 @@ static const struct panel_desc ontat_yx700wv03 = {
> > };
> > 
> > static const struct drm_display_mode ortustech_com37h3m_mode  = {
> > -	.clock = 22153,
> > +	.clock = 19842,
> > 	.hdisplay = 480,
> > 	.hsync_start = 480 + 8,
> > 	.hsync_end = 480 + 8 + 10,
> > -- 
> > 2.24.1
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2268 bytes --]

On Tue, Mar 03, 2020 at 02:57:45PM +0000, Peter Rosin wrote:
> 
> On 2020-03-03 15:20, Thierry Reding wrote:
> > On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
> >> On 2020-03-02 21:34, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> The currently listed dotclock disagrees with the currently
> >>> listed vrefresh rate. Change the dotclock to match the vrefresh.
> >>>
> >>> Someone tell me which (if either) of the dotclock or vreresh is
> >>> correct?
> >>
> >> TL/DR; I do not care if you change the refresh rate or the dotclock.
> >>
> >> The whole entry for that panel in simple-panel is dubious. The panel
> >> is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
> >> with the SELLVDS pin).  With Jeida you can, as usual, omit the 4th
> >> data channel and use the panel with RGB666. In either case, you need
> >> an LVDS signal and nothing else...
> >>
> >> The panel can also rotate the picture 180 degrees using the RL/UD pin.
> >>
> >> These options are of course not expressed in the simple panel driver
> >> (and we have always used fixed signals for those pins in our designs,
> >> IIRC). As far as I'm concerned, the panel can be removed from
> >> simple-panel. Our device trees are nowadays correctly expressing the
> >> hardware with an LVDS encoder between the RGB output and the panel
> >> and points to the panel-lvds driver for the panel.
> > 
> > How do you make sure that you always bind against the correct driver? If
> > it matches simple-panel and panel-lvds, it's not deterministically going
> > to pick the right one. Well, it may actually be deterministic on Linux,
> > but perhaps only by accident.
> 
> You are probably right that it's fragile, but no problems so far. That
> said, I did wonder why the panel-lvds driver "wins" over simple-panel for
> 
> 	compatible = "sharp,lq150x1lg11", "panel-lvds";
> 
> I figured it was by design and didn't spend too much time thinking about
> it. Maybe I should have?

It's most likely because panel-lvds.o is linked into the kernel before
panel-simple.o and the first match wins. You may want to move the entry
to panel-lvds to make this a little more robust.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

[Peter Rosin]

On 2020-03-03 16:05, Thierry Reding wrote:
> On Tue, Mar 03, 2020 at 02:57:45PM +0000, Peter Rosin wrote:
>>
>> On 2020-03-03 15:20, Thierry Reding wrote:
>>> On Mon, Mar 02, 2020 at 10:53:56PM +0000, Peter Rosin wrote:
>>>> On 2020-03-02 21:34, Ville Syrjala wrote:
>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>
>>>>> The currently listed dotclock disagrees with the currently
>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>
>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>> correct?
>>>>
>>>> TL/DR; I do not care if you change the refresh rate or the dotclock.
>>>>
>>>> The whole entry for that panel in simple-panel is dubious. The panel
>>>> is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
>>>> with the SELLVDS pin).  With Jeida you can, as usual, omit the 4th
>>>> data channel and use the panel with RGB666. In either case, you need
>>>> an LVDS signal and nothing else...
>>>>
>>>> The panel can also rotate the picture 180 degrees using the RL/UD pin.
>>>>
>>>> These options are of course not expressed in the simple panel driver
>>>> (and we have always used fixed signals for those pins in our designs,
>>>> IIRC). As far as I'm concerned, the panel can be removed from
>>>> simple-panel. Our device trees are nowadays correctly expressing the
>>>> hardware with an LVDS encoder between the RGB output and the panel
>>>> and points to the panel-lvds driver for the panel.
>>>
>>> How do you make sure that you always bind against the correct driver? If
>>> it matches simple-panel and panel-lvds, it's not deterministically going
>>> to pick the right one. Well, it may actually be deterministic on Linux,
>>> but perhaps only by accident.
>>
>> You are probably right that it's fragile, but no problems so far. That
>> said, I did wonder why the panel-lvds driver "wins" over simple-panel for
>>
>> 	compatible = "sharp,lq150x1lg11", "panel-lvds";
>>
>> I figured it was by design and didn't spend too much time thinking about
>> it. Maybe I should have?
> 
> It's most likely because panel-lvds.o is linked into the kernel before
> panel-simple.o and the first match wins. You may want to move the entry
> to panel-lvds to make this a little more robust.

Ok, or because I dropped the simple-panel driver when we no longer
depended on it. Either way, what do you mean "move to [..] panel-lvds"?
It has no list of panels, you have to end with "panel-lvds" in the
compatible for the driver to bind.

Cheers,
Peter
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

[H. Nikolaus Schaller]

Hi,

> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
> 
>> I haven't looked into the driver code, but would it be
>> possible to specify .clock = 0 (or leave it out) to
>> calculate it bottom up? This would avoid such inconsistencies.
> 
> I'm going to remove .vrefresh entirely from the struct.
> It'll just be calculated from the other timings as needed.

Ok!

Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.

I'll give it a try and let you know.

BR and thanks,
Nikolaus

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Brian Masney]

On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> What Xorg prints doesn't mean anything. I don't think there will be errors
> in dmesg, you need to run something that does pageflips as fast as possible
> and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
> examples)

I assume that you mean modetest from
https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
Here's the modeset connector information:

id   encoder status      name    size (mm)  modes   encoders
32   31      connected   DSI-1   62x110     1       31
  modes:
        index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
  flags: ; type: preferred, driver

And the page flip results...

$ modetest -v -s 32:1080x1920
trying to open device 'msm'...done
setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
failed to set gamma: Function not implemented
freq: 13.50Hz
freq: 13.51Hz
freq: 13.51Hz

It's the same results with and without Ville's patch.

Here's the beginning of the glmark2 results with the x11-gl flavor:

=======================================================
    glmark2 2017.07
=======================================================
    OpenGL Information
    GL_VENDOR:     freedreno
    GL_RENDERER:   FD330
    GL_VERSION:    3.1 Mesa 20.0.0-devel
=======================================================
[build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
[build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
[texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
[texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
[texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
[shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
[shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
[shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
[shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
[bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
[bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
[bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
 38.462 ms
[pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
 FPS: 26 FrameTime: 38.462 ms
[desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
...

Brian


> 
> On 3/3/20 7:26 AM, Brian Masney wrote:
> > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> > > Another thing: did you verify that the panel still runs at 60hz (and not
> > > dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> > 
> > Yes, the panel is running at 60 HZ according to the Xorg log with
> > Ville's patch applied:
> > 
> >      modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
> >      1920 1922 1924 1926 (115.6 kHz eP)
> > 
> > I verified there's no underflow errors in dmesg.
> > 
> > If I recall correctly, the clock speeds that was in your tree was set
> > too low for the gpu_opp_table (that wouldn't cause this issue), but I
> > seem to recall there were some other clock speed mismatches. The
> > bandwidth requests weren't set on the RPM as well, so maybe that
> > contributed to the problem. That's done upstream with the msm8974
> > interconnect driver:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> > 
> > There's a separate known issue with 'pp done time out' errors that
> > occur on the framebuffer that started upstream several months ago with
> > the introduction of async commit support in the MSM driver. I tried
> > working around this by enabling the autorefresh feature but it's not
> > fully working yet and I hit a dead end since there's no docs available
> > publicly for this. The grim details are at:
> > 
> > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> > 
> > So I'm still OK with Ville's patch going in.
> > 
> > Brian
> > 
> > 
> > > 
> > > On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > > > 
> > > > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > > > the vrefresh
> > > > > > field for the actual refresh rate, while the dotclock field is
> > > > > > used for the
> > > > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > > > necessary otherwise
> > > > > > the panel would not work.
> > > > > > 
> > > > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > > > need to be some changes to msm driver.
> > > > > > 
> > > > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > > > 150000 value is
> > > > > > likely not optimal, just something that worked, this is something that
> > > > > > should have been checked with the downstream driver)
> > > > > 
> > > > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > > > you're talking about?
> > > > > 
> > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > > > 
> > > > > 
> > > > 
> > > > No, I'm talking about the DSI clock (the driver for it is in
> > > > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > > > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > > > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > > > enough (there is also rounding of the clock values to consider).
> > > > 
> > > > > I don't see any obvious clock values in the downstream command mode
> > > > > panel configuration:
> > > > > 
> > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > > > 
> > > > > 
> > > > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > > > and everything appears to be working fine. You can add my Tested-by if
> > > > > you end up applying this.
> > > > > 
> > > > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > > > 
> > > > > Brian
> > > > > 
> > > > > 
> > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > 
> > > > > > > The currently listed dotclock disagrees with the currently
> > > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > > 
> > > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > > correct?
> > > > > > > 
> > > > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > ---
> > > > > > >     drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > > >     1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > > > panasonic_vvx10f004b00 = {
> > > > > > >     };
> > > > > > >     static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > > > -    .clock = 150000,
> > > > > > > +    .clock = 125498,
> > > > > > >         .hdisplay = 1080,
> > > > > > >         .hsync_start = 1080 + 2,
> > > > > > >         .hsync_end = 1080 + 2 + 2,
> > > > > > > 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Jonathan Marek]

modetest should be printing "freq: 60.0Hz", so definitely something 
wrong there. Though I guess you have another problem since I would 
expect the patch to drop it to 30 and not 13.5.

(FYI glmark-x11 isn't vsynced which is why I specifically mentioned 
glmark-drm)

On 3/3/20 9:16 PM, Brian Masney wrote:
> On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
>> What Xorg prints doesn't mean anything. I don't think there will be errors
>> in dmesg, you need to run something that does pageflips as fast as possible
>> and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
>> examples)
> 
> I assume that you mean modetest from
> https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> Here's the modeset connector information:
> 
> id   encoder status      name    size (mm)  modes   encoders
> 32   31      connected   DSI-1   62x110     1       31
>    modes:
>          index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
>    #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
>    flags: ; type: preferred, driver
> 
> And the page flip results...
> 
> $ modetest -v -s 32:1080x1920
> trying to open device 'msm'...done
> setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> failed to set gamma: Function not implemented
> freq: 13.50Hz
> freq: 13.51Hz
> freq: 13.51Hz
> 
> It's the same results with and without Ville's patch.
> 
> Here's the beginning of the glmark2 results with the x11-gl flavor:
> 
> =======================================================
>      glmark2 2017.07
> =======================================================
>      OpenGL Information
>      GL_VENDOR:     freedreno
>      GL_RENDERER:   FD330
>      GL_VERSION:    3.1 Mesa 20.0.0-devel
> =======================================================
> [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
>   38.462 ms
> [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
>   FPS: 26 FrameTime: 38.462 ms
> [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> ...
> 
> Brian
> 
> 
>>
>> On 3/3/20 7:26 AM, Brian Masney wrote:
>>> On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
>>>> Another thing: did you verify that the panel still runs at 60hz (and not
>>>> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
>>>
>>> Yes, the panel is running at 60 HZ according to the Xorg log with
>>> Ville's patch applied:
>>>
>>>       modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
>>>       1920 1922 1924 1926 (115.6 kHz eP)
>>>
>>> I verified there's no underflow errors in dmesg.
>>>
>>> If I recall correctly, the clock speeds that was in your tree was set
>>> too low for the gpu_opp_table (that wouldn't cause this issue), but I
>>> seem to recall there were some other clock speed mismatches. The
>>> bandwidth requests weren't set on the RPM as well, so maybe that
>>> contributed to the problem. That's done upstream with the msm8974
>>> interconnect driver:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
>>>
>>> There's a separate known issue with 'pp done time out' errors that
>>> occur on the framebuffer that started upstream several months ago with
>>> the introduction of async commit support in the MSM driver. I tried
>>> working around this by enabling the autorefresh feature but it's not
>>> fully working yet and I hit a dead end since there's no docs available
>>> publicly for this. The grim details are at:
>>>
>>> https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
>>>
>>> So I'm still OK with Ville's patch going in.
>>>
>>> Brian
>>>
>>>
>>>>
>>>> On 3/2/20 10:28 PM, Jonathan Marek wrote:
>>>>>
>>>>> On 3/2/20 10:13 PM, Brian Masney wrote:
>>>>>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is a command mode panel and the the msm/mdp5 driver uses
>>>>>>> the vrefresh
>>>>>>> field for the actual refresh rate, while the dotclock field is
>>>>>>> used for the
>>>>>>> DSI clocks. The dotclock needed to be a bit higher than
>>>>>>> necessary otherwise
>>>>>>> the panel would not work.
>>>>>>>
>>>>>>> If you want to get rid of the separate clock/vrefresh fields there would
>>>>>>> need to be some changes to msm driver.
>>>>>>>
>>>>>>> (note I hadn't made the patch with upstreaming in mind, the
>>>>>>> 150000 value is
>>>>>>> likely not optimal, just something that worked, this is something that
>>>>>>> should have been checked with the downstream driver)
>>>>>>
>>>>>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>>>>>> you're talking about?
>>>>>>
>>>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>>>>>>
>>>>>>
>>>>>
>>>>> No, I'm talking about the DSI clock (the driver for it is in
>>>>> drm/msm/dsi/). For a command mode panel the front/back porches aren't
>>>>> relevant, but the dsi pixel/byte clock need to be a bit higher than
>>>>> 1920x1080x60. Since 125498 is a little higher than 124416 that might be
>>>>> enough (there is also rounding of the clock values to consider).
>>>>>
>>>>>> I don't see any obvious clock values in the downstream command mode
>>>>>> panel configuration:
>>>>>>
>>>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>>>>>>
>>>>>>
>>>>>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>>>>>> and everything appears to be working fine. You can add my Tested-by if
>>>>>> you end up applying this.
>>>>>>
>>>>>> Tested-by: Brian Masney <masneyb@onstation.org>
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>>>
>>>>>>>> The currently listed dotclock disagrees with the currently
>>>>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>>>>
>>>>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>>>>> correct?
>>>>>>>>
>>>>>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>>>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>>>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>>> ---
>>>>>>>>      drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>> index b24fdf239440..f958d8dfd760 100644
>>>>>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
>>>>>>>> panasonic_vvx10f004b00 = {
>>>>>>>>      };
>>>>>>>>      static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>>>>>> -    .clock = 150000,
>>>>>>>> +    .clock = 125498,
>>>>>>>>          .hdisplay = 1080,
>>>>>>>>          .hsync_start = 1080 + 2,
>>>>>>>>          .hsync_end = 1080 + 2 + 2,
>>>>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Brian Masney]

On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
> modetest should be printing "freq: 60.0Hz", so definitely something wrong
> there. Though I guess you have another problem since I would expect the
> patch to drop it to 30 and not 13.5.
> 
> (FYI glmark-x11 isn't vsynced which is why I specifically mentioned
> glmark-drm)

I tried compiling the drm variant and it was complaining about some
missing dependencies that I didn't see in Alpine Linux. I didn't try too
hard since I'm a bit short on time at this point since I'm starting a
new job on Monday and I have another side project that I want to finish
before then.

I suspect that the issue is caused by the introduction of the async
commit support in the MSM driver that introduced the ping/pong timeouts.
I'll try in a few weeks or so reverting those patches and see if that
affects the speed.

I'm still ok with Ville's patch going in given the existing slow state.
There's no clear path forward right now for the autocommit patch that I
linked to earlier in this thread. :(

Brian 

> 
> On 3/3/20 9:16 PM, Brian Masney wrote:
> > On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> > > What Xorg prints doesn't mean anything. I don't think there will be errors
> > > in dmesg, you need to run something that does pageflips as fast as possible
> > > and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
> > > examples)
> > 
> > I assume that you mean modetest from
> > https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> > Here's the modeset connector information:
> > 
> > id   encoder status      name    size (mm)  modes   encoders
> > 32   31      connected   DSI-1   62x110     1       31
> >    modes:
> >          index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
> >    #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
> >    flags: ; type: preferred, driver
> > 
> > And the page flip results...
> > 
> > $ modetest -v -s 32:1080x1920
> > trying to open device 'msm'...done
> > setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> > failed to set gamma: Function not implemented
> > freq: 13.50Hz
> > freq: 13.51Hz
> > freq: 13.51Hz
> > 
> > It's the same results with and without Ville's patch.
> > 
> > Here's the beginning of the glmark2 results with the x11-gl flavor:
> > 
> > =======================================================
> >      glmark2 2017.07
> > =======================================================
> >      OpenGL Information
> >      GL_VENDOR:     freedreno
> >      GL_RENDERER:   FD330
> >      GL_VERSION:    3.1 Mesa 20.0.0-devel
> > =======================================================
> > [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> > [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> > [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> > [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> > [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> > [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> > [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
> >   38.462 ms
> > [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> > [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> >   FPS: 26 FrameTime: 38.462 ms
> > [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> > ...
> > 
> > Brian
> > 
> > 
> > > 
> > > On 3/3/20 7:26 AM, Brian Masney wrote:
> > > > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> > > > > Another thing: did you verify that the panel still runs at 60hz (and not
> > > > > dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> > > > 
> > > > Yes, the panel is running at 60 HZ according to the Xorg log with
> > > > Ville's patch applied:
> > > > 
> > > >       modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
> > > >       1920 1922 1924 1926 (115.6 kHz eP)
> > > > 
> > > > I verified there's no underflow errors in dmesg.
> > > > 
> > > > If I recall correctly, the clock speeds that was in your tree was set
> > > > too low for the gpu_opp_table (that wouldn't cause this issue), but I
> > > > seem to recall there were some other clock speed mismatches. The
> > > > bandwidth requests weren't set on the RPM as well, so maybe that
> > > > contributed to the problem. That's done upstream with the msm8974
> > > > interconnect driver:
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> > > > 
> > > > There's a separate known issue with 'pp done time out' errors that
> > > > occur on the framebuffer that started upstream several months ago with
> > > > the introduction of async commit support in the MSM driver. I tried
> > > > working around this by enabling the autorefresh feature but it's not
> > > > fully working yet and I hit a dead end since there's no docs available
> > > > publicly for this. The grim details are at:
> > > > 
> > > > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> > > > 
> > > > So I'm still OK with Ville's patch going in.
> > > > 
> > > > Brian
> > > > 
> > > > 
> > > > > 
> > > > > On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > > > > > 
> > > > > > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > > > > > the vrefresh
> > > > > > > > field for the actual refresh rate, while the dotclock field is
> > > > > > > > used for the
> > > > > > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > > > > > necessary otherwise
> > > > > > > > the panel would not work.
> > > > > > > > 
> > > > > > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > > > > > need to be some changes to msm driver.
> > > > > > > > 
> > > > > > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > > > > > 150000 value is
> > > > > > > > likely not optimal, just something that worked, this is something that
> > > > > > > > should have been checked with the downstream driver)
> > > > > > > 
> > > > > > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > > > > > you're talking about?
> > > > > > > 
> > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > No, I'm talking about the DSI clock (the driver for it is in
> > > > > > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > > > > > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > > > > > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > > > > > enough (there is also rounding of the clock values to consider).
> > > > > > 
> > > > > > > I don't see any obvious clock values in the downstream command mode
> > > > > > > panel configuration:
> > > > > > > 
> > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > > > > > 
> > > > > > > 
> > > > > > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > > > > > and everything appears to be working fine. You can add my Tested-by if
> > > > > > > you end up applying this.
> > > > > > > 
> > > > > > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > > > > > 
> > > > > > > Brian
> > > > > > > 
> > > > > > > 
> > > > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > 
> > > > > > > > > The currently listed dotclock disagrees with the currently
> > > > > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > > > > 
> > > > > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > > > > correct?
> > > > > > > > > 
> > > > > > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > ---
> > > > > > > > >      drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > > > > >      1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > > > > > panasonic_vvx10f004b00 = {
> > > > > > > > >      };
> > > > > > > > >      static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > > > > > -    .clock = 150000,
> > > > > > > > > +    .clock = 125498,
> > > > > > > > >          .hdisplay = 1080,
> > > > > > > > >          .hsync_start = 1080 + 2,
> > > > > > > > >          .hsync_end = 1080 + 2 + 2,
> > > > > > > > > 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Jonathan Marek]

If I have time to kill over the weekend I'll do a new rebase of my Nexus 
5 patches (my last rebase was back in August on 5.2, and the panel was 
working correctly at 60Hz back then).

Looked at it again and it does look like your glmark was vsynced (glmark 
explicitly disables vsync so I guess you have it force-enabled) since 
the results are all 26-27 (X works a bit differently and gets double the 
framerate somehow?)

On 3/3/20 9:53 PM, Brian Masney wrote:
> On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
>> modetest should be printing "freq: 60.0Hz", so definitely something wrong
>> there. Though I guess you have another problem since I would expect the
>> patch to drop it to 30 and not 13.5.
>>
>> (FYI glmark-x11 isn't vsynced which is why I specifically mentioned
>> glmark-drm)
> 
> I tried compiling the drm variant and it was complaining about some
> missing dependencies that I didn't see in Alpine Linux. I didn't try too
> hard since I'm a bit short on time at this point since I'm starting a
> new job on Monday and I have another side project that I want to finish
> before then.
> 
> I suspect that the issue is caused by the introduction of the async
> commit support in the MSM driver that introduced the ping/pong timeouts.
> I'll try in a few weeks or so reverting those patches and see if that
> affects the speed.
> 
> I'm still ok with Ville's patch going in given the existing slow state.
> There's no clear path forward right now for the autocommit patch that I
> linked to earlier in this thread. :(
> 
> Brian
> 
>>
>> On 3/3/20 9:16 PM, Brian Masney wrote:
>>> On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
>>>> What Xorg prints doesn't mean anything. I don't think there will be errors
>>>> in dmesg, you need to run something that does pageflips as fast as possible
>>>> and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
>>>> examples)
>>>
>>> I assume that you mean modetest from
>>> https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
>>> Here's the modeset connector information:
>>>
>>> id   encoder status      name    size (mm)  modes   encoders
>>> 32   31      connected   DSI-1   62x110     1       31
>>>     modes:
>>>           index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
>>>     #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
>>>     flags: ; type: preferred, driver
>>>
>>> And the page flip results...
>>>
>>> $ modetest -v -s 32:1080x1920
>>> trying to open device 'msm'...done
>>> setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
>>> failed to set gamma: Function not implemented
>>> freq: 13.50Hz
>>> freq: 13.51Hz
>>> freq: 13.51Hz
>>>
>>> It's the same results with and without Ville's patch.
>>>
>>> Here's the beginning of the glmark2 results with the x11-gl flavor:
>>>
>>> =======================================================
>>>       glmark2 2017.07
>>> =======================================================
>>>       OpenGL Information
>>>       GL_VENDOR:     freedreno
>>>       GL_RENDERER:   FD330
>>>       GL_VERSION:    3.1 Mesa 20.0.0-devel
>>> =======================================================
>>> [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
>>> [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
>>> [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
>>> [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
>>> [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
>>> [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
>>> [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
>>> [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
>>> [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
>>> [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
>>> [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
>>> [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
>>> [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
>>> [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
>>>    38.462 ms
>>> [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
>>> [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
>>>    FPS: 26 FrameTime: 38.462 ms
>>> [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
>>> ...
>>>
>>> Brian
>>>
>>>
>>>>
>>>> On 3/3/20 7:26 AM, Brian Masney wrote:
>>>>> On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
>>>>>> Another thing: did you verify that the panel still runs at 60hz (and not
>>>>>> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
>>>>>
>>>>> Yes, the panel is running at 60 HZ according to the Xorg log with
>>>>> Ville's patch applied:
>>>>>
>>>>>        modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
>>>>>        1920 1922 1924 1926 (115.6 kHz eP)
>>>>>
>>>>> I verified there's no underflow errors in dmesg.
>>>>>
>>>>> If I recall correctly, the clock speeds that was in your tree was set
>>>>> too low for the gpu_opp_table (that wouldn't cause this issue), but I
>>>>> seem to recall there were some other clock speed mismatches. The
>>>>> bandwidth requests weren't set on the RPM as well, so maybe that
>>>>> contributed to the problem. That's done upstream with the msm8974
>>>>> interconnect driver:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
>>>>>
>>>>> There's a separate known issue with 'pp done time out' errors that
>>>>> occur on the framebuffer that started upstream several months ago with
>>>>> the introduction of async commit support in the MSM driver. I tried
>>>>> working around this by enabling the autorefresh feature but it's not
>>>>> fully working yet and I hit a dead end since there's no docs available
>>>>> publicly for this. The grim details are at:
>>>>>
>>>>> https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
>>>>>
>>>>> So I'm still OK with Ville's patch going in.
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>>
>>>>>> On 3/2/20 10:28 PM, Jonathan Marek wrote:
>>>>>>>
>>>>>>> On 3/2/20 10:13 PM, Brian Masney wrote:
>>>>>>>> On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> This is a command mode panel and the the msm/mdp5 driver uses
>>>>>>>>> the vrefresh
>>>>>>>>> field for the actual refresh rate, while the dotclock field is
>>>>>>>>> used for the
>>>>>>>>> DSI clocks. The dotclock needed to be a bit higher than
>>>>>>>>> necessary otherwise
>>>>>>>>> the panel would not work.
>>>>>>>>>
>>>>>>>>> If you want to get rid of the separate clock/vrefresh fields there would
>>>>>>>>> need to be some changes to msm driver.
>>>>>>>>>
>>>>>>>>> (note I hadn't made the patch with upstreaming in mind, the
>>>>>>>>> 150000 value is
>>>>>>>>> likely not optimal, just something that worked, this is something that
>>>>>>>>> should have been checked with the downstream driver)
>>>>>>>>
>>>>>>>> Is this the right clock frequency in the downstream MSM 3.4 kernel that
>>>>>>>> you're talking about?
>>>>>>>>
>>>>>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> No, I'm talking about the DSI clock (the driver for it is in
>>>>>>> drm/msm/dsi/). For a command mode panel the front/back porches aren't
>>>>>>> relevant, but the dsi pixel/byte clock need to be a bit higher than
>>>>>>> 1920x1080x60. Since 125498 is a little higher than 124416 that might be
>>>>>>> enough (there is also rounding of the clock values to consider).
>>>>>>>
>>>>>>>> I don't see any obvious clock values in the downstream command mode
>>>>>>>> panel configuration:
>>>>>>>>
>>>>>>>> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
>>>>>>>>
>>>>>>>>
>>>>>>>> Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
>>>>>>>> and everything appears to be working fine. You can add my Tested-by if
>>>>>>>> you end up applying this.
>>>>>>>>
>>>>>>>> Tested-by: Brian Masney <masneyb@onstation.org>
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 3/2/20 3:34 PM, Ville Syrjala wrote:
>>>>>>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>>>>>
>>>>>>>>>> The currently listed dotclock disagrees with the currently
>>>>>>>>>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>>>>>>>>>
>>>>>>>>>> Someone tell me which (if either) of the dotclock or vreresh is
>>>>>>>>>> correct?
>>>>>>>>>>
>>>>>>>>>> Cc: Jonathan Marek <jonathan@marek.ca>
>>>>>>>>>> Cc: Brian Masney <masneyb@onstation.org>
>>>>>>>>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>>>>>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>>>>> ---
>>>>>>>>>>       drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>>>>>>>>>       1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>>>> b/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>>>> index b24fdf239440..f958d8dfd760 100644
>>>>>>>>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>>>>>>>>> @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
>>>>>>>>>> panasonic_vvx10f004b00 = {
>>>>>>>>>>       };
>>>>>>>>>>       static const struct drm_display_mode lg_acx467akm_7_mode = {
>>>>>>>>>> -    .clock = 150000,
>>>>>>>>>> +    .clock = 125498,
>>>>>>>>>>           .hdisplay = 1080,
>>>>>>>>>>           .hsync_start = 1080 + 2,
>>>>>>>>>>           .hsync_end = 1080 + 2 + 2,
>>>>>>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Linus Walleij]

On Mon, Mar 2, 2020 at 9:49 PM Jonathan Marek <jonathan@marek.ca> wrote:

> This is a command mode panel and the the msm/mdp5 driver uses the
> vrefresh field for the actual refresh rate, while the dotclock field is
> used for the DSI clocks. The dotclock needed to be a bit higher than
> necessary otherwise the panel would not work.

I don't know if this predates the support for defining DSI clocks
but for what we have in the kernel right now this is wrong.

struct mipi_dsi_device contains:

 * @hs_rate: maximum lane frequency for high speed mode in hertz, this should
 * be set to the real limits of the hardware, zero is only accepted for
 * legacy drivers
 * @lp_rate: maximum lane frequency for low power mode in hertz, this should
 * be set to the real limits of the hardware, zero is only accepted for
 * legacy drivers

The MDP driver should use these frequencies for a DSI command
mode panel, and the panel driver should define them.

These two clocks are/can be/should be completely orthogonal to
the dotclock/pixelclock inside the panel, which is likely driven from
its own crystal directly from the panel-internal framebuffer.

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Brian Masney]

On Tue, Mar 03, 2020 at 10:04:56PM -0500, Jonathan Marek wrote:
> If I have time to kill over the weekend I'll do a new rebase of my Nexus 5
> patches (my last rebase was back in August on 5.2, and the panel was working
> correctly at 60Hz back then).

That would be great if you have time to look at the panel. My
out-of-tree patches for this phone are at
https://github.com/masneyb/linux/commits/v5.5-nexus5.
A high-level description of those patches are on the cover letter:
https://github.com/masneyb/nexus-5-upstream/blob/master/out-of-tree-patches/upstream-patches/v5.5/0000-cover-letter.patch

A description of what works and what I've done upstream for this device
is described at:
https://masneyb.github.io/nexus-5-upstream/

Brian



> 
> Looked at it again and it does look like your glmark was vsynced (glmark
> explicitly disables vsync so I guess you have it force-enabled) since the
> results are all 26-27 (X works a bit differently and gets double the
> framerate somehow?)
> 
> On 3/3/20 9:53 PM, Brian Masney wrote:
> > On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
> > > modetest should be printing "freq: 60.0Hz", so definitely something wrong
> > > there. Though I guess you have another problem since I would expect the
> > > patch to drop it to 30 and not 13.5.
> > > 
> > > (FYI glmark-x11 isn't vsynced which is why I specifically mentioned
> > > glmark-drm)
> > 
> > I tried compiling the drm variant and it was complaining about some
> > missing dependencies that I didn't see in Alpine Linux. I didn't try too
> > hard since I'm a bit short on time at this point since I'm starting a
> > new job on Monday and I have another side project that I want to finish
> > before then.
> > 
> > I suspect that the issue is caused by the introduction of the async
> > commit support in the MSM driver that introduced the ping/pong timeouts.
> > I'll try in a few weeks or so reverting those patches and see if that
> > affects the speed.
> > 
> > I'm still ok with Ville's patch going in given the existing slow state.
> > There's no clear path forward right now for the autocommit patch that I
> > linked to earlier in this thread. :(
> > 
> > Brian
> > 
> > > 
> > > On 3/3/20 9:16 PM, Brian Masney wrote:
> > > > On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> > > > > What Xorg prints doesn't mean anything. I don't think there will be errors
> > > > > in dmesg, you need to run something that does pageflips as fast as possible
> > > > > and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
> > > > > examples)
> > > > 
> > > > I assume that you mean modetest from
> > > > https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> > > > Here's the modeset connector information:
> > > > 
> > > > id   encoder status      name    size (mm)  modes   encoders
> > > > 32   31      connected   DSI-1   62x110     1       31
> > > >     modes:
> > > >           index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
> > > >     #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
> > > >     flags: ; type: preferred, driver
> > > > 
> > > > And the page flip results...
> > > > 
> > > > $ modetest -v -s 32:1080x1920
> > > > trying to open device 'msm'...done
> > > > setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> > > > failed to set gamma: Function not implemented
> > > > freq: 13.50Hz
> > > > freq: 13.51Hz
> > > > freq: 13.51Hz
> > > > 
> > > > It's the same results with and without Ville's patch.
> > > > 
> > > > Here's the beginning of the glmark2 results with the x11-gl flavor:
> > > > 
> > > > =======================================================
> > > >       glmark2 2017.07
> > > > =======================================================
> > > >       OpenGL Information
> > > >       GL_VENDOR:     freedreno
> > > >       GL_RENDERER:   FD330
> > > >       GL_VERSION:    3.1 Mesa 20.0.0-devel
> > > > =======================================================
> > > > [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> > > > [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> > > > [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> > > > [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> > > > [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> > > > [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> > > > [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> > > > [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> > > > [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> > > > [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> > > > [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> > > > [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> > > > [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> > > > [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
> > > >    38.462 ms
> > > > [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> > > > [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> > > >    FPS: 26 FrameTime: 38.462 ms
> > > > [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> > > > ...
> > > > 
> > > > Brian
> > > > 
> > > > 
> > > > > 
> > > > > On 3/3/20 7:26 AM, Brian Masney wrote:
> > > > > > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> > > > > > > Another thing: did you verify that the panel still runs at 60hz (and not
> > > > > > > dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> > > > > > 
> > > > > > Yes, the panel is running at 60 HZ according to the Xorg log with
> > > > > > Ville's patch applied:
> > > > > > 
> > > > > >        modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
> > > > > >        1920 1922 1924 1926 (115.6 kHz eP)
> > > > > > 
> > > > > > I verified there's no underflow errors in dmesg.
> > > > > > 
> > > > > > If I recall correctly, the clock speeds that was in your tree was set
> > > > > > too low for the gpu_opp_table (that wouldn't cause this issue), but I
> > > > > > seem to recall there were some other clock speed mismatches. The
> > > > > > bandwidth requests weren't set on the RPM as well, so maybe that
> > > > > > contributed to the problem. That's done upstream with the msm8974
> > > > > > interconnect driver:
> > > > > > 
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> > > > > > 
> > > > > > There's a separate known issue with 'pp done time out' errors that
> > > > > > occur on the framebuffer that started upstream several months ago with
> > > > > > the introduction of async commit support in the MSM driver. I tried
> > > > > > working around this by enabling the autorefresh feature but it's not
> > > > > > fully working yet and I hit a dead end since there's no docs available
> > > > > > publicly for this. The grim details are at:
> > > > > > 
> > > > > > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> > > > > > 
> > > > > > So I'm still OK with Ville's patch going in.
> > > > > > 
> > > > > > Brian
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > > > > > > > 
> > > > > > > > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > > > > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > > > > > > > the vrefresh
> > > > > > > > > > field for the actual refresh rate, while the dotclock field is
> > > > > > > > > > used for the
> > > > > > > > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > > > > > > > necessary otherwise
> > > > > > > > > > the panel would not work.
> > > > > > > > > > 
> > > > > > > > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > > > > > > > need to be some changes to msm driver.
> > > > > > > > > > 
> > > > > > > > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > > > > > > > 150000 value is
> > > > > > > > > > likely not optimal, just something that worked, this is something that
> > > > > > > > > > should have been checked with the downstream driver)
> > > > > > > > > 
> > > > > > > > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > > > > > > > you're talking about?
> > > > > > > > > 
> > > > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > No, I'm talking about the DSI clock (the driver for it is in
> > > > > > > > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > > > > > > > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > > > > > > > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > > > > > > > enough (there is also rounding of the clock values to consider).
> > > > > > > > 
> > > > > > > > > I don't see any obvious clock values in the downstream command mode
> > > > > > > > > panel configuration:
> > > > > > > > > 
> > > > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > > > > > > > and everything appears to be working fine. You can add my Tested-by if
> > > > > > > > > you end up applying this.
> > > > > > > > > 
> > > > > > > > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > > > > > > > 
> > > > > > > > > Brian
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > 
> > > > > > > > > > > The currently listed dotclock disagrees with the currently
> > > > > > > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > > > > > > 
> > > > > > > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > > > > > > correct?
> > > > > > > > > > > 
> > > > > > > > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > > > > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > > > > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > > ---
> > > > > > > > > > >       drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > > > > > > >       1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > > > > > > > panasonic_vvx10f004b00 = {
> > > > > > > > > > >       };
> > > > > > > > > > >       static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > > > > > > > -    .clock = 150000,
> > > > > > > > > > > +    .clock = 125498,
> > > > > > > > > > >           .hdisplay = 1080,
> > > > > > > > > > >           .hsync_start = 1080 + 2,
> > > > > > > > > > >           .hsync_end = 1080 + 2 + 2,
> > > > > > > > > > > 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Brian Masney]

On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
> modetest should be printing "freq: 60.0Hz", so definitely something wrong
> there. Though I guess you have another problem since I would expect the
> patch to drop it to 30 and not 13.5.

So I reverted the following three commits related to the async commit
support in the MSM driver:

    d934a712c5e6 ("drm/msm: add atomic traces")
    2d99ced787e3 ("drm/msm: async commit support")
    194fc68d7a49 ("drm/msm/dpu: async commit support")

The modetest results now look much better:

# With existing 150000 clock rate on the panel
$ modetest -v -s 32:1080x19
setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
failed to set gamma: Function not implemented
freq: 59.40Hz
freq: 59.69Hz
freq: 59.69Hz
...

With Ville's patch the frequency drops slightly.

# With 125498 clock rate on the panel
$ modetest -v -s 32:1080x19
freq: 55.44Hz
freq: 55.09Hz
freq: 55.88Hz
...

Brian

> 
> (FYI glmark-x11 isn't vsynced which is why I specifically mentioned
> glmark-drm)
> 
> On 3/3/20 9:16 PM, Brian Masney wrote:
> > On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> > > What Xorg prints doesn't mean anything. I don't think there will be errors
> > > in dmesg, you need to run something that does pageflips as fast as possible
> > > and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
> > > examples)
> > 
> > I assume that you mean modetest from
> > https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest ?
> > Here's the modeset connector information:
> > 
> > id   encoder status      name    size (mm)  modes   encoders
> > 32   31      connected   DSI-1   62x110     1       31
> >    modes:
> >          index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
> >    #0 1080x1920 71.71 1080 1082 1084 1086 1920 1922 1924 1926 150000
> >    flags: ; type: preferred, driver
> > 
> > And the page flip results...
> > 
> > $ modetest -v -s 32:1080x1920
> > trying to open device 'msm'...done
> > setting mode 1080x1920-71.71Hz@XR24 on connectors 32, crtc 50
> > failed to set gamma: Function not implemented
> > freq: 13.50Hz
> > freq: 13.51Hz
> > freq: 13.51Hz
> > 
> > It's the same results with and without Ville's patch.
> > 
> > Here's the beginning of the glmark2 results with the x11-gl flavor:
> > 
> > =======================================================
> >      glmark2 2017.07
> > =======================================================
> >      OpenGL Information
> >      GL_VENDOR:     freedreno
> >      GL_RENDERER:   FD330
> >      GL_VERSION:    3.1 Mesa 20.0.0-devel
> > =======================================================
> > [build] use-vbo=false: FPS: 26 FrameTime: 38.462 ms
> > [build] use-vbo=true: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=nearest: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=linear: FPS: 26 FrameTime: 38.462 ms
> > [texture] texture-filter=mipmap: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=gouraud: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=blinn-phong-inf: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=phong: FPS: 27 FrameTime: 37.037 ms
> > [shading] shading=cel: FPS: 26 FrameTime: 38.462 ms
> > [bump] bump-render=high-poly: FPS: 27 FrameTime: 37.037 ms
> > [bump] bump-render=normals: FPS: 27 FrameTime: 37.037 ms
> > [bump] bump-render=height: FPS: 27 FrameTime: 37.037 ms
> > [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 25 FrameTime: 40.000 ms
> > [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 26 FrameTime:
> >   38.462 ms
> > [pulsar] light=false:quads=5:texture=false: FPS: 26 FrameTime: 38.462 ms
> > [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> >   FPS: 26 FrameTime: 38.462 ms
> > [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms
> > ...
> > 
> > Brian
> > 
> > 
> > > 
> > > On 3/3/20 7:26 AM, Brian Masney wrote:
> > > > On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> > > > > Another thing: did you verify that the panel still runs at 60hz (and not
> > > > > dropping frames to 30hz)? IIRC that was the behavior with lower clock.
> > > > 
> > > > Yes, the panel is running at 60 HZ according to the Xorg log with
> > > > Ville's patch applied:
> > > > 
> > > >       modeset(0): Modeline "1080x1920"x60.0  125.50  1080 1082 1084 1086
> > > >       1920 1922 1924 1926 (115.6 kHz eP)
> > > > 
> > > > I verified there's no underflow errors in dmesg.
> > > > 
> > > > If I recall correctly, the clock speeds that was in your tree was set
> > > > too low for the gpu_opp_table (that wouldn't cause this issue), but I
> > > > seem to recall there were some other clock speed mismatches. The
> > > > bandwidth requests weren't set on the RPM as well, so maybe that
> > > > contributed to the problem. That's done upstream with the msm8974
> > > > interconnect driver:
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/interconnect/qcom/msm8974.c
> > > > 
> > > > There's a separate known issue with 'pp done time out' errors that
> > > > occur on the framebuffer that started upstream several months ago with
> > > > the introduction of async commit support in the MSM driver. I tried
> > > > working around this by enabling the autorefresh feature but it's not
> > > > fully working yet and I hit a dead end since there's no docs available
> > > > publicly for this. The grim details are at:
> > > > 
> > > > https://lore.kernel.org/lkml/20191230020053.26016-2-masneyb@onstation.org/
> > > > 
> > > > So I'm still OK with Ville's patch going in.
> > > > 
> > > > Brian
> > > > 
> > > > 
> > > > > 
> > > > > On 3/2/20 10:28 PM, Jonathan Marek wrote:
> > > > > > 
> > > > > > On 3/2/20 10:13 PM, Brian Masney wrote:
> > > > > > > On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > This is a command mode panel and the the msm/mdp5 driver uses
> > > > > > > > the vrefresh
> > > > > > > > field for the actual refresh rate, while the dotclock field is
> > > > > > > > used for the
> > > > > > > > DSI clocks. The dotclock needed to be a bit higher than
> > > > > > > > necessary otherwise
> > > > > > > > the panel would not work.
> > > > > > > > 
> > > > > > > > If you want to get rid of the separate clock/vrefresh fields there would
> > > > > > > > need to be some changes to msm driver.
> > > > > > > > 
> > > > > > > > (note I hadn't made the patch with upstreaming in mind, the
> > > > > > > > 150000 value is
> > > > > > > > likely not optimal, just something that worked, this is something that
> > > > > > > > should have been checked with the downstream driver)
> > > > > > > 
> > > > > > > Is this the right clock frequency in the downstream MSM 3.4 kernel that
> > > > > > > you're talking about?
> > > > > > > 
> > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > No, I'm talking about the DSI clock (the driver for it is in
> > > > > > drm/msm/dsi/). For a command mode panel the front/back porches aren't
> > > > > > relevant, but the dsi pixel/byte clock need to be a bit higher than
> > > > > > 1920x1080x60. Since 125498 is a little higher than 124416 that might be
> > > > > > enough (there is also rounding of the clock values to consider).
> > > > > > 
> > > > > > > I don't see any obvious clock values in the downstream command mode
> > > > > > > panel configuration:
> > > > > > > 
> > > > > > > https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
> > > > > > > 
> > > > > > > 
> > > > > > > Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
> > > > > > > and everything appears to be working fine. You can add my Tested-by if
> > > > > > > you end up applying this.
> > > > > > > 
> > > > > > > Tested-by: Brian Masney <masneyb@onstation.org>
> > > > > > > 
> > > > > > > Brian
> > > > > > > 
> > > > > > > 
> > > > > > > > On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > > > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > 
> > > > > > > > > The currently listed dotclock disagrees with the currently
> > > > > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > > > > 
> > > > > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > > > > correct?
> > > > > > > > > 
> > > > > > > > > Cc: Jonathan Marek <jonathan@marek.ca>
> > > > > > > > > Cc: Brian Masney <masneyb@onstation.org>
> > > > > > > > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > ---
> > > > > > > > >      drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > > > > > > > >      1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > index b24fdf239440..f958d8dfd760 100644
> > > > > > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > > > > > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > > > > > > > > panasonic_vvx10f004b00 = {
> > > > > > > > >      };
> > > > > > > > >      static const struct drm_display_mode lg_acx467akm_7_mode = {
> > > > > > > > > -    .clock = 150000,
> > > > > > > > > +    .clock = 125498,
> > > > > > > > >          .hdisplay = 1080,
> > > > > > > > >          .hsync_start = 1080 + 2,
> > > > > > > > >          .hsync_end = 1080 + 2 + 2,
> > > > > > > > > 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2

[Stefan Riedmüller]

Hi Ville, hi Christoph,

On 03.03.20 14:13, Christoph Fritz wrote:
> On Mon, 2020-03-02 at 22:34 +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>
>> The currently listed dotclock disagrees with the currently
>> listed vrefresh rate. Change the dotclock to match the vrefresh.
>>
>> Someone tell me which (if either) of the dotclock or vreresh is
>> correct?

The 40 MHz clock comes from the datasheet which states this as the typical 
clock frequency. But the valid range reaches from 30 MHz to 50 MHz. The 
datasheet also states a 60 Hz frame rate so setting the clock to the 
corresponding frequency makes sense to me.

I gave it a little test here and both values work for me.

Regards,
Stefan

> 
> This display (a controller is included) has a wide tolerance range.
> 
> Adapting clock should be fine while keeping vrefresh rate at 60 Hz.
> 
> I guess an even better alternative would be to change this config to a
> pixelclock describing one like the other auo panels.
> 
> But at the moment I'm not having a display here.
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Jonathan Marek]

The msm DSI driver does predate the addition of those fields and doesn't 
use them at all.

Seems like it would be a bit of a hack too, since the frequency we want 
to use is not the "real limits of the hardware"..

On 3/4/20 4:10 AM, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:49 PM Jonathan Marek <jonathan@marek.ca> wrote:
> 
>> This is a command mode panel and the the msm/mdp5 driver uses the
>> vrefresh field for the actual refresh rate, while the dotclock field is
>> used for the DSI clocks. The dotclock needed to be a bit higher than
>> necessary otherwise the panel would not work.
> 
> I don't know if this predates the support for defining DSI clocks
> but for what we have in the kernel right now this is wrong.
> 
> struct mipi_dsi_device contains:
> 
>   * @hs_rate: maximum lane frequency for high speed mode in hertz, this should
>   * be set to the real limits of the hardware, zero is only accepted for
>   * legacy drivers
>   * @lp_rate: maximum lane frequency for low power mode in hertz, this should
>   * be set to the real limits of the hardware, zero is only accepted for
>   * legacy drivers
> 
> The MDP driver should use these frequencies for a DSI command
> mode panel, and the panel driver should define them.
> 
> These two clocks are/can be/should be completely orthogonal to
> the dotclock/pixelclock inside the panel, which is likely driven from
> its own crystal directly from the panel-internal framebuffer.
> 
> Yours,
> Linus Walleij
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

[Linus Walleij]

On Wed, Mar 4, 2020 at 2:17 PM Jonathan Marek <jonathan@marek.ca> wrote:

[hs_rate / lp_rate]

> The msm DSI driver does predate the addition of those fields and doesn't
> use them at all.

I think it would be benficient to switch to these fields, because then
the .clock field (dot/pixelclock) is not abused to contain what I guess
is the desires hs_rate.

> Seems like it would be a bit of a hack too, since the frequency we want
> to use is not the "real limits of the hardware"..

That just means "clock it as high as the panel can take".

Normally that would come from the vendor datasheet of
the panel.

If you don't have the datasheet, whatever you use in the vendor
tree is fine, I suppose what is currently in .clock is fine.

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

[Sam Ravnborg]

Hi Peter.

> >>
> >> That said, I have no idea whatsoever if others have started using this
> >> panel entry. My guess is that it has zero users, but who can tell?
> > 
> > A quick grep shows that arch/arm/boot/dts/at91-nattis-2-natte-2.dts is
> > the only device tree that uses this panel in the upstream kernel.
> 
> This is our design, and what made us originally add the entry to simple
> panel, but as I said, we no longer need simple-panel support for it...

With the only upstream user using panel-lvds we should delete
it from panel-simple.
With all the features it does not belong in panel-simple anyway.
Peter - care to send a patch for that?

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Revert "drm/panel: simple: Add support for Sharp LQ150X1LG11 panels"

[Peter Rosin]

This reverts commit 0f9cdd743f7f8d470fff51b11250f02fc554cf1b.

The interface of the panel is LVDS, not parallel.
The color depth is RGB888, not RGB565.
The panel has additional features, making it not so simple.
The only user (upstream) of this panel is appropriately using panel-lvds.

Suggested-by: Thierry Reding <thierry.reding@gmail.com>
Suggested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
 drivers/gpu/drm/panel/panel-simple.c | 27 ---------------------------
 1 file changed, 27 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index e14c14ac62b5..fb8d61f5ae5d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2768,30 +2768,6 @@ static const struct panel_desc sharp_lq123p1jx31 = {
 	},
 };
 
-static const struct drm_display_mode sharp_lq150x1lg11_mode = {
-	.clock = 71100,
-	.hdisplay = 1024,
-	.hsync_start = 1024 + 168,
-	.hsync_end = 1024 + 168 + 64,
-	.htotal = 1024 + 168 + 64 + 88,
-	.vdisplay = 768,
-	.vsync_start = 768 + 37,
-	.vsync_end = 768 + 37 + 2,
-	.vtotal = 768 + 37 + 2 + 8,
-	.vrefresh = 60,
-};
-
-static const struct panel_desc sharp_lq150x1lg11 = {
-	.modes = &sharp_lq150x1lg11_mode,
-	.num_modes = 1,
-	.bpc = 6,
-	.size = {
-		.width = 304,
-		.height = 228,
-	},
-	.bus_format = MEDIA_BUS_FMT_RGB565_1X16,
-};
-
 static const struct display_timing sharp_ls020b1dd01d_timing = {
 	.pixelclock = { 2000000, 4200000, 5000000 },
 	.hactive = { 240, 240, 240 },
@@ -3465,9 +3441,6 @@ static const struct of_device_id platform_of_match[] = {
 	}, {
 		.compatible = "sharp,lq123p1jx31",
 		.data = &sharp_lq123p1jx31,
-	}, {
-		.compatible = "sharp,lq150x1lg11",
-		.data = &sharp_lq150x1lg11,
 	}, {
 		.compatible = "sharp,ls020b1dd01d",
 		.data = &sharp_ls020b1dd01d,
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

[H. Nikolaus Schaller]

> Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi,
> 
>> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
>> 
>>> I haven't looked into the driver code, but would it be
>>> possible to specify .clock = 0 (or leave it out) to
>>> calculate it bottom up? This would avoid such inconsistencies.
>> 
>> I'm going to remove .vrefresh entirely from the struct.
>> It'll just be calculated from the other timings as needed.
> 
> Ok!
> 
> Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.
> 
> I'll give it a try and let you know.

Ok, here is a new parameter set within data sheet limits for both
panel variants:

static const struct drm_display_mode ortustech_com37h3m_mode  = {
	.clock = 22153,
	.hdisplay = 480,
	.hsync_start = 480 + 40,
	.hsync_end = 480 + 40 + 10,
	.htotal = 480 + 40 + 10 + 40,
	.vdisplay = 640,
	.vsync_start = 640 + 4,
	.vsync_end = 640 + 4 + 2,
	.vtotal = 640 + 4 + 2 + 4,
	.vrefresh = 60,
	.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
};

I have tested on our omap3 based board and didn't find an issue
so you can insert into your patch.

BR and thanks,
Nikolaus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6

[Marco Felsch]

On 20-03-03 16:52, Ville Syrjälä wrote:
> On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > Hi Ville,
> > 
> > On 20-03-02 22:34, Ville Syrjala wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > The currently listed dotclock disagrees with the currently
> > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > 
> > > Someone tell me which (if either) of the dotclock or vreresh is
> > > correct?
> > 
> > Pls, check the datasheet which is linked within the comment. We hit the
> > vrefresh exactly if we are in SYNC MODE.
> 
> It's too much work to start hunting datasheets for all these
> and figuring out what's going on in each case. Pls just
> inform me which way is correct if you know the details.

How do you know that the clock is wrong if it is to much work? As I said
the clock is completely fine.

Regards,
  Marco

> > 
> > Regards,
> >   Marco
> > 
> > > Cc: Andreas Pretzsch <apr@cn-eng.de>
> > > Cc: Marco Felsch <m.felsch@pengutronix.de>
> > > Cc: Thierry Reding <treding@nvidia.com>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > index 93e5bc32fb59..35750229189f 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -1342,7 +1342,7 @@ static const struct panel_desc dlc_dlc1010gig = {
> > >  };
> > >  
> > >  static const struct drm_display_mode edt_et035012dm6_mode = {
> > > -	.clock = 6500,
> > > +	.clock = 6414,
> > >  	.hdisplay = 320,
> > >  	.hsync_start = 320 + 20,
> > >  	.hsync_end = 320 + 20 + 30,
> > > -- 
> > > 2.24.1
> > > 
> > > 
> > 
> > -- 
> > Pengutronix e.K.                           |                             |
> > Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> > 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> -- 
> Ville Syrjälä
> Intel
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock

[Linus Walleij]

Hi Ville,

On Mon, Mar 2, 2020 at 9:34 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:

>         .mode = {
>                 /* The internal pixel clock of the NT35510 is 20 MHz */
> -               .clock = 20000000,
> +               .clock = 23581,

I double checked this with the datasheet NT35510 Application Note V0.07 HYDIS
and all documentation is in line with the comment: the internal clock
frequency of
the dotclock is 20 MHz so this should be set to 20000 (kHz) sorry for putting
the three orders of magnitude too big number there :P

This clock isn't used by any drivers because this is a command mode DSI
panel with a DSI link clocked from the host. (hs_rate or lp_rate).

The internal formula shows how the actual vrefresh can be calculated for
the display in respone to setting of the internal registers, see page 34:
https://dflund.se/~triad/NT35510-appnote.pdf

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks

[Linus Walleij]

Hi Ville!

On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:

> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

This display is particularly peculiar since it uses
the ITU-T packed streams and like DSI those have
a different clocking than whatever is clocked out to the
actual display by the pixel clock.

Datasheet is here:
https://dflund.se/~triad/krad/dlink-dir-685/ILI9322DS_V1.12.pdf

I see I have consistently set the clocks two orders of
magnitude wrong in this driver, mea culpa :P
But I checked them all and what I think you should
do is just divide them all by 100 and leave as-is.

>  /* Serial RGB modes */
>  static const struct drm_display_mode srgb_320x240_mode = {
> -       .clock = 2453500,
> +       .clock = 14478,

Please set to 24535.

>  static const struct drm_display_mode srgb_360x240_mode = {
> -       .clock = 2700000,
> +       .clock = 10014,

Please set to 27000.

>  /* This is the only mode listed for parallel RGB in the datasheet */
>  static const struct drm_display_mode prgb_320x240_mode = {
> -       .clock = 6400000,
> +       .clock = 6429,

Please set to 64000.

>  static const struct drm_display_mode yuv_640x320_mode = {
> -       .clock = 2454000,
> +       .clock = 18954,

Please set to 24540.

>  static const struct drm_display_mode yuv_720x360_mode = {
> -       .clock = 2700000,
> +       .clock = 22911,

Please set to 27000.

>  /* BT.656 VGA mode, 640x480 */
>  static const struct drm_display_mode itu_r_bt_656_640_mode = {
> -       .clock = 2454000,
> +       .clock = 27480,

Please set to 24540.

>  /* BT.656 D1 mode 720x480 */
>  static const struct drm_display_mode itu_r_bt_656_720_mode = {
> -       .clock = 2700000,
> +       .clock = 29880,

Please set to 27000.

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks

[Linus Walleij]

On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:

> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

These are better than what is currently in the driver
at least, we don't know the real dotclocks. (No datasheet.)
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/panel: simple: Add support for Sharp LQ150X1LG11 panels"

[Sam Ravnborg]

Hi Peter.


On Thu, Mar 05, 2020 at 01:07:07PM +0000, Peter Rosin wrote:
> This reverts commit 0f9cdd743f7f8d470fff51b11250f02fc554cf1b.
> 
> The interface of the panel is LVDS, not parallel.
> The color depth is RGB888, not RGB565.
> The panel has additional features, making it not so simple.
> The only user (upstream) of this panel is appropriately using panel-lvds.
> 
> Suggested-by: Thierry Reding <thierry.reding@gmail.com>
> Suggested-by: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Peter Rosin <peda@axentia.se>

Thanks, applied to drm-misc-next and pushed out.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

[Ville Syrjälä]

On Thu, Mar 05, 2020 at 08:41:43PM +0100, H. Nikolaus Schaller wrote:
> 
> > Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > 
> > Hi,
> > 
> >> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
> >> 
> >>> I haven't looked into the driver code, but would it be
> >>> possible to specify .clock = 0 (or leave it out) to
> >>> calculate it bottom up? This would avoid such inconsistencies.
> >> 
> >> I'm going to remove .vrefresh entirely from the struct.
> >> It'll just be calculated from the other timings as needed.
> > 
> > Ok!
> > 
> > Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.
> > 
> > I'll give it a try and let you know.
> 
> Ok, here is a new parameter set within data sheet limits for both
> panel variants:
> 
> static const struct drm_display_mode ortustech_com37h3m_mode  = {
> 	.clock = 22153,
> 	.hdisplay = 480,
> 	.hsync_start = 480 + 40,
> 	.hsync_end = 480 + 40 + 10,
> 	.htotal = 480 + 40 + 10 + 40,
> 	.vdisplay = 640,
> 	.vsync_start = 640 + 4,
> 	.vsync_end = 640 + 4 + 2,
> 	.vtotal = 640 + 4 + 2 + 4,
> 	.vrefresh = 60,
> 	.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> };
> 
> I have tested on our omap3 based board and didn't find an issue
> so you can insert into your patch.

Migth be better if you send that so we get proper attribution and
you can explain the change properly in the commit message.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

[H. Nikolaus Schaller]

> Am 09.03.2020 um 14:00 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
> 
> On Thu, Mar 05, 2020 at 08:41:43PM +0100, H. Nikolaus Schaller wrote:
>> 
>>> Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>> 
>>> Hi,
>>> 
>>>> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä <ville.syrjala@linux.intel.com>:
>>>> 
>>>>> I haven't looked into the driver code, but would it be
>>>>> possible to specify .clock = 0 (or leave it out) to
>>>>> calculate it bottom up? This would avoid such inconsistencies.
>>>> 
>>>> I'm going to remove .vrefresh entirely from the struct.
>>>> It'll just be calculated from the other timings as needed.
>>> 
>>> Ok!
>>> 
>>> Anyways we should fix the panel timings so that it is compatible to .vrefresh = 60.
>>> 
>>> I'll give it a try and let you know.
>> 
>> Ok, here is a new parameter set within data sheet limits for both
>> panel variants:
>> 
>> static const struct drm_display_mode ortustech_com37h3m_mode  = {
>> 	.clock = 22153,
>> 	.hdisplay = 480,
>> 	.hsync_start = 480 + 40,
>> 	.hsync_end = 480 + 40 + 10,
>> 	.htotal = 480 + 40 + 10 + 40,
>> 	.vdisplay = 640,
>> 	.vsync_start = 640 + 4,
>> 	.vsync_end = 640 + 4 + 2,
>> 	.vtotal = 640 + 4 + 2 + 4,
>> 	.vrefresh = 60,
>> 	.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
>> };
>> 
>> I have tested on our omap3 based board and didn't find an issue
>> so you can insert into your patch.
> 
> Migth be better if you send that so we get proper attribution and
> you can explain the change properly in the commit message.

Ok, will do asap.

BR and thanks,
Nikolaus

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6

[Ville Syrjälä]

On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> On 20-03-03 16:52, Ville Syrjälä wrote:
> > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > > Hi Ville,
> > > 
> > > On 20-03-02 22:34, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > The currently listed dotclock disagrees with the currently
> > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > 
> > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > correct?
> > > 
> > > Pls, check the datasheet which is linked within the comment. We hit the
> > > vrefresh exactly if we are in SYNC MODE.
> > 
> > It's too much work to start hunting datasheets for all these
> > and figuring out what's going on in each case. Pls just
> > inform me which way is correct if you know the details.
> 
> How do you know that the clock is wrong if it is to much work? As I said
> the clock is completely fine.

htotal*vtotal*vrefresh != clock, so one or both are incorrect.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 01/33] drm/panel-novatek-nt35510: Fix dotclock

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The dotclock is three orders of magnitude out. Fix it.

v2: Just set it to 20MHz (Linus)

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index b4c014126781..4a8fa908a2cf 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -1019,7 +1019,7 @@ static const struct nt35510_config nt35510_hydis_hva40wv1 = {
 	 */
 	.mode = {
 		/* The internal pixel clock of the NT35510 is 20 MHz */
-		.clock = 20000000,
+		.clock = 20000,
 		.hdisplay = 480,
 		.hsync_start = 480 + 2, /* HFP = 2 */
 		.hsync_end = 480 + 2 + 0, /* HSync = 0 */
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 04/33] drm/panel-ilitek-ili9322: Fix dotclocks

[Ville Syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The listed dotclocks are two orders of mangnitude out.
Fix them.

v2: Just divide everything by 100 (Linus)

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index f394d53a7da4..09935520e606 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -540,7 +540,7 @@ static int ili9322_enable(struct drm_panel *panel)
 
 /* Serial RGB modes */
 static const struct drm_display_mode srgb_320x240_mode = {
-	.clock = 2453500,
+	.clock = 24535,
 	.hdisplay = 320,
 	.hsync_start = 320 + 359,
 	.hsync_end = 320 + 359 + 1,
@@ -554,7 +554,7 @@ static const struct drm_display_mode srgb_320x240_mode = {
 };
 
 static const struct drm_display_mode srgb_360x240_mode = {
-	.clock = 2700000,
+	.clock = 27000,
 	.hdisplay = 360,
 	.hsync_start = 360 + 35,
 	.hsync_end = 360 + 35 + 1,
@@ -569,7 +569,7 @@ static const struct drm_display_mode srgb_360x240_mode = {
 
 /* This is the only mode listed for parallel RGB in the datasheet */
 static const struct drm_display_mode prgb_320x240_mode = {
-	.clock = 6400000,
+	.clock = 64000,
 	.hdisplay = 320,
 	.hsync_start = 320 + 38,
 	.hsync_end = 320 + 38 + 1,
@@ -584,7 +584,7 @@ static const struct drm_display_mode prgb_320x240_mode = {
 
 /* YUV modes */
 static const struct drm_display_mode yuv_640x320_mode = {
-	.clock = 2454000,
+	.clock = 24540,
 	.hdisplay = 640,
 	.hsync_start = 640 + 252,
 	.hsync_end = 640 + 252 + 1,
@@ -598,7 +598,7 @@ static const struct drm_display_mode yuv_640x320_mode = {
 };
 
 static const struct drm_display_mode yuv_720x360_mode = {
-	.clock = 2700000,
+	.clock = 27000,
 	.hdisplay = 720,
 	.hsync_start = 720 + 252,
 	.hsync_end = 720 + 252 + 1,
@@ -613,7 +613,7 @@ static const struct drm_display_mode yuv_720x360_mode = {
 
 /* BT.656 VGA mode, 640x480 */
 static const struct drm_display_mode itu_r_bt_656_640_mode = {
-	.clock = 2454000,
+	.clock = 24540,
 	.hdisplay = 640,
 	.hsync_start = 640 + 3,
 	.hsync_end = 640 + 3 + 1,
@@ -628,7 +628,7 @@ static const struct drm_display_mode itu_r_bt_656_640_mode = {
 
 /* BT.656 D1 mode 720x480 */
 static const struct drm_display_mode itu_r_bt_656_720_mode = {
-	.clock = 2700000,
+	.clock = 27000,
 	.hdisplay = 720,
 	.hsync_start = 720 + 3,
 	.hsync_end = 720 + 3 + 1,
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/33] drm/panel-novatek-nt35510: Fix dotclock

[Linus Walleij]

On Mon, Mar 9, 2020 at 2:36 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:

> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The dotclock is three orders of magnitude out. Fix it.
>
> v2: Just set it to 20MHz (Linus)
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 04/33] drm/panel-ilitek-ili9322: Fix dotclocks

[Linus Walleij]

On Mon, Mar 9, 2020 at 2:38 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:

> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The listed dotclocks are two orders of mangnitude out.
> Fix them.
>
> v2: Just divide everything by 100 (Linus)
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6

[Marco Felsch]

On 20-03-09 15:18, Ville Syrjälä wrote:
> On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> > On 20-03-03 16:52, Ville Syrjälä wrote:
> > > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > > > Hi Ville,
> > > > 
> > > > On 20-03-02 22:34, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > 
> > > > > The currently listed dotclock disagrees with the currently
> > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > 
> > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > correct?
> > > > 
> > > > Pls, check the datasheet which is linked within the comment. We hit the
> > > > vrefresh exactly if we are in SYNC MODE.
> > > 
> > > It's too much work to start hunting datasheets for all these
> > > and figuring out what's going on in each case. Pls just
> > > inform me which way is correct if you know the details.
> > 
> > How do you know that the clock is wrong if it is to much work? As I said
> > the clock is completely fine.
> 
> htotal*vtotal*vrefresh != clock, so one or both are incorrect.

I checked the values using this equation:
clock / (htotal * vtotal) = vrefresh.

Regards,
  Marco
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6

[Ville Syrjälä]

On Tue, Mar 10, 2020 at 08:05:32AM +0100, Marco Felsch wrote:
> On 20-03-09 15:18, Ville Syrjälä wrote:
> > On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> > > On 20-03-03 16:52, Ville Syrjälä wrote:
> > > > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > > > > Hi Ville,
> > > > > 
> > > > > On 20-03-02 22:34, Ville Syrjala wrote:
> > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > 
> > > > > > The currently listed dotclock disagrees with the currently
> > > > > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > > > > 
> > > > > > Someone tell me which (if either) of the dotclock or vreresh is
> > > > > > correct?
> > > > > 
> > > > > Pls, check the datasheet which is linked within the comment. We hit the
> > > > > vrefresh exactly if we are in SYNC MODE.
> > > > 
> > > > It's too much work to start hunting datasheets for all these
> > > > and figuring out what's going on in each case. Pls just
> > > > inform me which way is correct if you know the details.
> > > 
> > > How do you know that the clock is wrong if it is to much work? As I said
> > > the clock is completely fine.
> > 
> > htotal*vtotal*vrefresh != clock, so one or both are incorrect.
> 
> I checked the values using this equation:
> clock / (htotal * vtotal) = vrefresh.

I guess you truncated instead of rounding to nearest. With round to
nearest we get vrefresh=61. The actual number being 60.8...

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/33] drm/panel-lg-lg4573: Fix dotclock

[Ville Syrjälä]

On Tue, Mar 03, 2020 at 06:24:25AM +0100, Heiko Schocher wrote:
> Hello Ville Syrjala,
> 
> Am 02.03.2020 um 21:34 schrieb Ville Syrjala:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > 
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> 
> Your clock fix is correct, thanks!
> 
> > 
> > Cc: Heiko Schocher <hs@denx.de>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >   drivers/gpu/drm/panel/panel-lg-lg4573.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Reviewed-by: Heiko Schocher <hs@denx.de>

Thanks. Pushed to drm-misc-next.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/33] drm/panel-novatek-nt35510: Fix dotclock

[Ville Syrjälä]

On Mon, Mar 09, 2020 at 04:33:19PM +0100, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 2:36 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The dotclock is three orders of magnitude out. Fix it.
> >
> > v2: Just set it to 20MHz (Linus)
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Thanks. Pushed to drm-misc-next.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28

[Ville Syrjälä]

On Tue, Mar 03, 2020 at 07:00:12AM -0600, Adam Ford wrote:
> On Mon, Mar 2, 2020 at 2:36 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> >
> > Cc: Adam Ford <aford173@gmail.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > index 225be4757a85..3a46b82722f5 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -2277,7 +2277,7 @@ static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
> >  };
> >
> >  static const struct drm_display_mode logicpd_type_28_mode = {
> > -       .clock = 9000,
> > +       .clock = 9107,
> 
> This should be OK.  The max dotclk frequency of this panel is 12MHz,
> so 9.107MHz should be just fine.
> 
> Reviewed-by: Adam Ford <aford173@gmail.com>

Thanks. Pushed to drm-misc-next.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks

[Ville Syrjälä]

On Sat, Mar 07, 2020 at 03:40:11PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The currently listed dotclocks disagree with the currently
> > listed vrefresh rates. Change the dotclocks to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> These are better than what is currently in the driver
> at least, we don't know the real dotclocks. (No datasheet.)
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Thanks. Pushed to drm-misc-next.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 04/33] drm/panel-ilitek-ili9322: Fix dotclocks

[Ville Syrjälä]

On Mon, Mar 09, 2020 at 04:33:56PM +0100, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 2:38 PM Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The listed dotclocks are two orders of mangnitude out.
> > Fix them.
> >
> > v2: Just divide everything by 100 (Linus)
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Thanks. Pushed to drm-misc-next.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01

[Fabio Estevam]

Hi Ville,

On Mon, Mar 2, 2020 at 5:36 PM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 5ce1328fd7dc..6b48c02af112 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3368,7 +3368,7 @@ static const struct panel_desc urt_umsh_8596md_parallel = {
>  };
>
>  static const struct drm_display_mode vl050_8048nt_c01_mode = {
> -       .clock = 33333,
> +       .clock = 34540,

I don't have access to hardware to test this change at the moment, but
looking at the panel datasheet I see that 34.54MHz is still inside the
valid range:

Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock

[Ville Syrjälä]

On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> Hi,
> 
> Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > 
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> 
> The values came that way from the vendor .
> And lookin at other Leadtek display datasheets, 60Hz should be the
> correct refresh rate.
> 
> The display is also running happily at the 69MHz of
> your patch, so
> 
> Tested-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>

Thanks for confirming.

I think this patch the last one with a huge difference between
vrefresh and clock. So once this goes in I'm thinking of declaring
the remaining patches as not important and pushing ahead with the
mode dieting. Can someone ack this so I can get it in?

> Heiko
> 
> > 
> > Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > index 76ecf2de9c44..113ab9c0396b 100644
> > --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
> >  	.vsync_end	= 1280 + 30 + 4,
> >  	.vtotal		= 1280 + 30 + 4 + 12,
> >  	.vrefresh	= 60,
> > -	.clock		= 41600,
> > +	.clock		= 69217,
> >  	.width_mm	= 62,
> >  	.height_mm	= 110,
> >  };
> > 
> 
> 
> 

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock

[Heiko Stuebner]

Am Donnerstag, 2. April 2020, 15:13:10 CEST schrieb Ville Syrjälä:
> On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> > Hi,
> > 
> > Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > The currently listed dotclock disagrees with the currently
> > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > 
> > > Someone tell me which (if either) of the dotclock or vreresh is
> > > correct?
> > 
> > The values came that way from the vendor .
> > And lookin at other Leadtek display datasheets, 60Hz should be the
> > correct refresh rate.
> > 
> > The display is also running happily at the 69MHz of
> > your patch, so
> > 
> > Tested-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> 
> Thanks for confirming.
> 
> I think this patch the last one with a huge difference between
> vrefresh and clock. So once this goes in I'm thinking of declaring
> the remaining patches as not important and pushing ahead with the
> mode dieting. Can someone ack this so I can get it in?

hmm, not sure which one you want, so please pick one
Acked-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>

or for the address I use whan applying drm-misc commits:
Acked-by: Heiko Stuebner <heiko@sntech.de>


Heiko

> > > 
> > > Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > index 76ecf2de9c44..113ab9c0396b 100644
> > > --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
> > >  	.vsync_end	= 1280 + 30 + 4,
> > >  	.vtotal		= 1280 + 30 + 4 + 12,
> > >  	.vrefresh	= 60,
> > > -	.clock		= 41600,
> > > +	.clock		= 69217,
> > >  	.width_mm	= 62,
> > >  	.height_mm	= 110,
> > >  };
> > > 
> > 
> > 
> > 
> 
> 




_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock

[Sam Ravnborg]

Hi Ville.

On Thu, Apr 02, 2020 at 04:13:10PM +0300, Ville Syrjälä wrote:
> On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> > Hi,
> > 
> > Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > The currently listed dotclock disagrees with the currently
> > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > > 
> > > Someone tell me which (if either) of the dotclock or vreresh is
> > > correct?
> > 
> > The values came that way from the vendor .
> > And lookin at other Leadtek display datasheets, 60Hz should be the
> > correct refresh rate.
> > 
> > The display is also running happily at the 69MHz of
> > your patch, so
> > 
> > Tested-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> 
> Thanks for confirming.
> 
> I think this patch the last one with a huge difference between
> vrefresh and clock. So once this goes in I'm thinking of declaring
> the remaining patches as not important and pushing ahead with the
> mode dieting. Can someone ack this so I can get it in?

You have done a very good job following up on the individual panels and
the above seems like a good plan moving forward.
So for the remaining patches:

Acked-by: Sam Ravnborg <sam@ravnborg.org>

	Sam
> 
> > Heiko
> > 
> > > 
> > > Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
> > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > index 76ecf2de9c44..113ab9c0396b 100644
> > > --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
> > >  	.vsync_end	= 1280 + 30 + 4,
> > >  	.vtotal		= 1280 + 30 + 4 + 12,
> > >  	.vrefresh	= 60,
> > > -	.clock		= 41600,
> > > +	.clock		= 69217,
> > >  	.width_mm	= 62,
> > >  	.height_mm	= 110,
> > >  };
> > > 
> > 
> > 
> > 
> 
> -- 
> Ville Syrjälä
> Intel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel