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(-)
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 */
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
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 */
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
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.
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,
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
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.
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,
于 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,
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设备。
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,
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
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,
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
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.
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, };
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,
};
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,
};
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,
};
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
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,
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
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.
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,
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,
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
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.
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,
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,
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.
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.
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,
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,
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,
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,
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,
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
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 |
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
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.
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
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...
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,
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,
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,
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,
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,
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,
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
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.
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,
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,
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,
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
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 MAXCLK 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 MAXCLK 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
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
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
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.
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
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,
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,
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,
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
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.
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,
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,
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
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
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
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
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
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,
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
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,
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,
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,
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
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,
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,
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,
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/cl...
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/ms...
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,
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/cl...
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/ms...
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,
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/cl...
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/ms...
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,
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/driv...
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/cl...
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/ms...
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,
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/driv...
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/cl...
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/ms...
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,
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/driv...
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/cl...
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/ms...
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, >
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/driv...
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/cl...
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/ms...
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, >>
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/driv...
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/cl... > >
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/ms... > > > 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, > > >
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/driv...
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/cl... >> >> > > 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/ms... >> >> >> 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, >>>>
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/...
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/driv...
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/cl... > > > > > > > > > > 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/ms... > > > > > > > > > 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, > > > > >
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/driv...
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/cl... > >
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/ms... > > > 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, > > >
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
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
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
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
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.
dri-devel@lists.freedesktop.org
-
Adam Ford -
Brian Masney -
Christoph Fritz -
Fabio Estevam -
H. Nikolaus Schaller -
Heiko Schocher -
Heiko Stuebner -
Icenowy Zheng -
Jonathan Marek -
Linus Walleij -
Marco Felsch -
Peter Rosin -
Sam Ravnborg -
Stefan Riedmüller -
Thierry Reding -
Ville Syrjala -
Ville Syrjälä
-
Vladimir Zapolskiy