Message ID | 20230219114553.288057-2-frank@oltmanns.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp818083wrn; Sun, 19 Feb 2023 04:08:34 -0800 (PST) X-Google-Smtp-Source: AK7set9qoCCCNHqVbehzpjDOsqO/mHWt/1VWafnCelT1xi05H2eLU+aej+CoHwQm+XaPGKr8DNaQ X-Received: by 2002:a17:907:7b07:b0:878:7f6e:38a7 with SMTP id mn7-20020a1709077b0700b008787f6e38a7mr7430765ejc.44.1676808514574; Sun, 19 Feb 2023 04:08:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676808514; cv=none; d=google.com; s=arc-20160816; b=vEgYPxHpePtua0/SsS8US3cbnDpkkPpPGL9/t+tX2ny1ep4GzsCLpwWHsQqv+c7qkz PbKgcKmTuLXS1WN3LFQmqhT5SPql4Fk6cdwu/j+4hl+0WrMQHr+h4vQyJsqGo3h70N8p Wvpduw/lb5pWz71g95kffmKx3sw0ihszaWVwysYZKXgo9VIDVBAgGT31DCPXhcdL753s btNRMR94luHY5DFPTGpcrYZB3uHAqWGcRS7gbnn7MPH0C+YlARZdFwq08eklzZra5ahz W/YpGXkuwjrj7wRsNXBQ+QcxCh6x4pxiXq18VrQebg2QeXuXvxjT9JWJo+TlP1BUB8KO FhIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=8s5cyNEZ69bCI7i4TE/gwmJDIVWf0jgsyM+wk8nT1gY=; b=Fwy+jBgFPm2suAmrg7wXZiRGyF9r7fzyduM7bGcla0ZTzBQz/gxqRZzACAoP5SWszF y3ICPCK77pJ+inh8T0IO8k3gaHgbT+D/EyI088Yt0HSH2rXvWAm6W13Nt638xvQWr2LC XbBwVdqDpABmWStLFRudgC3B0LWuDhsRGXRK5mmhiGwCH8rmRauHJsP1FpZ4avqWv7Hk MxxQ9G6UwyCyIDjuzhiIYXw1cYOVa0qNIAQQjMuOhf/nzw87J3wOHbJcdUpRt7bfo0b4 QepBc27w1IxGi/JpbSs5oeMvNkuoTokfOTd2ZYyNN4GB0nnSIevTUHpbkJfNkHc7nOTg TKmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=s3wUanb3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v14-20020aa7d9ce000000b004acb302a730si12605224eds.70.2023.02.19.04.08.08; Sun, 19 Feb 2023 04:08:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=s3wUanb3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229925AbjBSLqa (ORCPT <rfc822;nanshango2@gmail.com> + 99 others); Sun, 19 Feb 2023 06:46:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229786AbjBSLqZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 19 Feb 2023 06:46:25 -0500 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050:0:465::101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF9FDCA27 for <linux-kernel@vger.kernel.org>; Sun, 19 Feb 2023 03:46:19 -0800 (PST) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4PKNzr1FXvz9sTx; Sun, 19 Feb 2023 12:46:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1676807176; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8s5cyNEZ69bCI7i4TE/gwmJDIVWf0jgsyM+wk8nT1gY=; b=s3wUanb3YMmzXRANmsUL8lF+o9wOEVWd3y/FWEjtg+7HBePxjG3AreJ23l6BxZtNaPsvB6 0LBtV2Tyf17CzJcwwrq905k6uBdrBs1MPVipxfe4ITTKtEPe8KdPtdPDLL2ZlKKIvIwqSZ xUXSQeefBi5+YJLoUN6Y8qSRfMNlI8spIaVqrrZ02Uwut5tUrNeSGGlZuYSsY9vLOrvSV8 XQuxZ2BtLc8LYzuy1D3MCMBzKh/Og+O206xdb+vqtBENxQub+D6XuQ2TCptObgc61Lu9vX doSpstvqiKbAas+ZPWJLb/CyhaAE2tuVu5naGAJkXlna4z7OzD2Zsut5sL++1A== From: Frank Oltmanns <frank@oltmanns.dev> To: =?utf-8?q?Guido_G=C3=BCnther?= <agx@sigxcpu.org>, Purism Kernel Team <kernel@puri.sm>, Ondrej Jirman <megous@megous.com>, Thierry Reding <thierry.reding@gmail.com>, Sam Ravnborg <sam@ravnborg.org>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, dri-devel@lists.freedesktop.org (open list:DRM PANEL DRIVERS), linux-kernel@vger.kernel.org (open list) Cc: Frank Oltmanns <frank@oltmanns.dev> Subject: [PATCH 1/1] drm/panel: st7703: Fix vertical refresh rate of XBD599 Date: Sun, 19 Feb 2023 12:45:53 +0100 Message-Id: <20230219114553.288057-2-frank@oltmanns.dev> In-Reply-To: <20230219114553.288057-1-frank@oltmanns.dev> References: <20230219114553.288057-1-frank@oltmanns.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4PKNzr1FXvz9sTx X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758261164913597718?= X-GMAIL-MSGID: =?utf-8?q?1758261164913597718?= |
Series |
drm/panel: st7703: Fix vertical refresh rate of XBD599
|
|
Commit Message
Frank Oltmanns
Feb. 19, 2023, 11:45 a.m. UTC
Fix the XBD599 panel's slight visual stutter by correcting the pixel clock speed so that the panel's 60Hz vertical refresh rate is met. Set the clock speed using the underlying formula instead of a magic number. To have a consistent procedure for both panels, set the JH057N panel's clock also as a formula. --- drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Hi, On Sun, Feb 19, 2023 at 12:45:53PM +0100, Frank Oltmanns wrote: > Fix the XBD599 panel's slight visual stutter by correcting the pixel > clock speed so that the panel's 60Hz vertical refresh rate is met. > > Set the clock speed using the underlying formula instead of a magic > number. To have a consistent procedure for both panels, set the JH057N > panel's clock also as a formula. > --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index 6747ca237ced..cd7d631f7573 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = { > .vsync_start = 1440 + 20, > .vsync_end = 1440 + 20 + 4, > .vtotal = 1440 + 20 + 4 + 12, > - .clock = 75276, > + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000, > .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, > .width_mm = 65, > .height_mm = 130, > @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = { > .vsync_start = 1440 + 18, > .vsync_end = 1440 + 18 + 10, > .vtotal = 1440 + 18 + 10 + 17, > - .clock = 69000, > + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, > .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, > .width_mm = 68, > .height_mm = 136, Reviewed-by: Guido Günther <agx@sigxcpu.org> (I've seen your other patches but it will be some days until I can test the jh057n00900 panel). Cheers, -- Guido > -- > 2.39.1 >
On Sun, Feb 19, 2023 at 12:45:53PM +0100, Frank Oltmanns wrote: > Fix the XBD599 panel's slight visual stutter by correcting the pixel > clock speed so that the panel's 60Hz vertical refresh rate is met. > > Set the clock speed using the underlying formula instead of a magic > number. To have a consistent procedure for both panels, set the JH057N > panel's clock also as a formula. > > --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index 6747ca237ced..cd7d631f7573 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = { > .vsync_start = 1440 + 20, > .vsync_end = 1440 + 20 + 4, > .vtotal = 1440 + 20 + 4 + 12, > - .clock = 75276, > + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000, > .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, > .width_mm = 65, > .height_mm = 130, > @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = { > .vsync_start = 1440 + 18, > .vsync_end = 1440 + 18 + 10, > .vtotal = 1440 + 18 + 10 + 17, > - .clock = 69000, > + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, As for pinephone, A64 can't produce 74.844 MHz precisely, so this will not work. Better fix is to alter the mode so that clock can be something the only SoC this panel is used with can actually produce. See eg. https://github.com/megous/linux/commit/dd070679d717e7f34af7558563698240a43981a6 which is tested to actually produce 60Hz by measuring the vsync events against the CPU timer. Your patch will not produce the intended effect. kind regards, o. > .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, > .width_mm = 68, > .height_mm = 136, > -- > 2.39.1 >
Hi Ondřej, hi all, Ondřej Jirman <megous@megous.com> writes: > On Sun, Feb 19, 2023 at 12:45:53PM +0100, Frank Oltmanns wrote: >> Fix the XBD599 panel’s slight visual stutter by correcting the pixel >> clock speed so that the panel’s 60Hz vertical refresh rate is met. >> >> Set the clock speed using the underlying formula instead of a magic >> number. To have a consistent procedure for both panels, set the JH057N >> panel’s clock also as a formula. >> >> — >> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++– >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff –git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c >> index 6747ca237ced..cd7d631f7573 100644 >> — a/drivers/gpu/drm/panel/panel-sitronix-st7703.c >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c >> @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = { >> .vsync_start = 1440 + 20, >> .vsync_end = 1440 + 20 + 4, >> .vtotal = 1440 + 20 + 4 + 12, >> - .clock = 75276, >> + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000, >> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, >> .width_mm = 65, >> .height_mm = 130, >> @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = { >> .vsync_start = 1440 + 18, >> .vsync_end = 1440 + 18 + 10, >> .vtotal = 1440 + 18 + 10 + 17, >> - .clock = 69000, >> + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, > > As for pinephone, A64 can’t produce 74.844 MHz precisely, so this will not work. > > Better fix is to alter the mode so that clock can be something the only SoC this > panel is used with can actually produce. > > See eg. <https://github.com/megous/linux/commit/dd070679d717e7f34af7558563698240a43981a6> > which is tested to actually produce 60Hz by measuring the vsync events against > the CPU timer. > > Your patch will not produce the intended effect. > > kind regards, > o. > The TL;DR of my upcoming musings are: Thank you very much for your feedback! Any recommendations for an informative read about the topic that you or anybody else has, is greatly appreciated. How did you measure the vsync events? Were you using vblank interrupts [1]? I have to admit that I tested only visually and couldn’t spot a difference between your patch and mine. I’ll need to put more thinking into this, and maybe you or anyone reading this can help me with that. My interpretation of the `struct drm_display_mode` documentation [2] was, that these are logical dimensions/clocks that somewhere down the stack are converted to their physical/hardware representation. But now I’ve read the description of the struct’s “crtc_clock” member more carefully. It says: “Actual pixel or dot clock in the hardware. This differs from the logical @clock when e.g. using interlacing, double-clocking, stereo modes or other fancy stuff that changes the timings and signals actually sent over the wire.” So, can I say that if we don’t use “interlacing, double-clocking, stereo modes or other fancy stuff” that `crtc_clock` will be equal to `clock` and therefore we have to choose `clock` according to the SoC’s capabilities? Also, I haven’t found a source about which values to use for the front and back porch part of the panel and why can you just “arbitrarily” change those. My assumption is, that those are just extra pixels we can add to make the dimensions match the ratio of clock and vertical refresh rate. At least that seems to be, what you did in your patch. But again, no source to back my assumption about the range the porches can have. I’ve put the following docs on my “to read and understand” list: • Allwinner A64 User Manual (to learn more about the SoC’s TCON0 and what clock’s the SoC can produce) • drm-internals.rst • “Rendering PinePhone’s display” [3], to learn why it produces 69 MHz. • Your commit message for the PinePhone Pro panel [4] (found on your blog: <https://xnux.eu/log/>) Is there anything else I should add? Thank you again and best regards, Frank [1] <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_vblank.c> [2] <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_modes.h#n198> [3] <https://lupyuen.github.io/articles/de> [4] <https://github.com/megous/linux/commit/a173b114c9323c718530280b3a918d0925edaa6a> >> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, >> .width_mm = 68, >> .height_mm = 136, >> – >> 2.39.1 >>
Hi Ondřej, hi Guido, On 2023-02-19 at 13:35:42 +0100, Ondřej Jirman <megous@megous.com> wrote: > On Sun, Feb 19, 2023 at 12:45:53PM +0100, Frank Oltmanns wrote: >> Fix the XBD599 panel’s slight visual stutter by correcting the pixel >> clock speed so that the panel’s 60Hz vertical refresh rate is met. >> >> Set the clock speed using the underlying formula instead of a magic >> number. To have a consistent procedure for both panels, set the JH057N >> panel’s clock also as a formula. >> >> — >> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++– >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff –git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c >> index 6747ca237ced..cd7d631f7573 100644 >> — a/drivers/gpu/drm/panel/panel-sitronix-st7703.c >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c >> @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = { >> .vsync_start = 1440 + 20, >> .vsync_end = 1440 + 20 + 4, >> .vtotal = 1440 + 20 + 4 + 12, >> - .clock = 75276, >> + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000, >> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, >> .width_mm = 65, >> .height_mm = 130, >> @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = { >> .vsync_start = 1440 + 18, >> .vsync_end = 1440 + 18 + 10, >> .vtotal = 1440 + 18 + 10 + 17, >> - .clock = 69000, >> + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, > > As for pinephone, A64 can’t produce 74.844 MHz precisely, so this will not work. > > Better fix is to alter the mode so that clock can be something the only SoC this > panel is used with can actually produce. > > See eg. <https://github.com/megous/linux/commit/dd070679d717e7f34af7558563698240a43981a6> > which is tested to actually produce 60Hz by measuring the vsync events against > the CPU timer. I did some testing using a 60fps video I produced using the following command: ffmpeg -f lavfi -i testsrc=duration=10:size=80x50:rate=60 -vf “drawtext=text=%{n}:fontsize=36:r=60:x=(w-tw)/2: y=h-(1*lh):fontcolor=white:box=1:boxcolor=0x00000099” test_80x50.mp4 This 10-second video shows an increasing number on every frame, which makes it easy to spot dropped frames by recording the playback with a camera that can record more than 60fps (I used a 240fps camera). When playing back that video with your current drm-6.2 branch I get a steady 60fps. But applying either your or my patch to mainline, only helps very little. Frames are being skipped more often than not in both cases. Therefore, I need to investigate more and retract the patch for now. The other two patches I sent earlier, however, are far more important for making the pinephone usable on mainline. Best regards, Frank > > Your patch will not produce the intended effect. > > kind regards, > o. > >> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, >> .width_mm = 68, >> .height_mm = 136, >> – >> 2.39.1 >>
On Sun, Feb 19, 2023 at 6:46 AM Frank Oltmanns <frank@oltmanns.dev> wrote: > > Fix the XBD599 panel's slight visual stutter by correcting the pixel > clock speed so that the panel's 60Hz vertical refresh rate is met. > > Set the clock speed using the underlying formula instead of a magic > number. To have a consistent procedure for both panels, set the JH057N > panel's clock also as a formula. > --- Hi Frank, Just wanted to let you know that this appears to be missing your Signed-off-by:. Thanks, -- Slade > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index 6747ca237ced..cd7d631f7573 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = { > .vsync_start = 1440 + 20, > .vsync_end = 1440 + 20 + 4, > .vtotal = 1440 + 20 + 4 + 12, > - .clock = 75276, > + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000, > .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, > .width_mm = 65, > .height_mm = 130, > @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = { > .vsync_start = 1440 + 18, > .vsync_end = 1440 + 18 + 10, > .vtotal = 1440 + 18 + 10 + 17, > - .clock = 69000, > + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, > .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, > .width_mm = 68, > .height_mm = 136, > -- > 2.39.1 >
Hi, On Sun, Feb 26, 2023 at 04:17:32PM +0100, Frank Oltmanns wrote: > Hi Ondřej, > hi Guido, > > On 2023-02-19 at 13:35:42 +0100, Ondřej Jirman <megous@megous.com> wrote: > > > On Sun, Feb 19, 2023 at 12:45:53PM +0100, Frank Oltmanns wrote: > >> Fix the XBD599 panel’s slight visual stutter by correcting the pixel > >> clock speed so that the panel’s 60Hz vertical refresh rate is met. > >> > >> Set the clock speed using the underlying formula instead of a magic > >> number. To have a consistent procedure for both panels, set the JH057N > >> panel’s clock also as a formula. > >> > >> — > >> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++– > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff –git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > >> index 6747ca237ced..cd7d631f7573 100644 > >> — a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > >> @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = { > >> .vsync_start = 1440 + 20, > >> .vsync_end = 1440 + 20 + 4, > >> .vtotal = 1440 + 20 + 4 + 12, > >> - .clock = 75276, > >> + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000, > >> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, > >> .width_mm = 65, > >> .height_mm = 130, > >> @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = { > >> .vsync_start = 1440 + 18, > >> .vsync_end = 1440 + 18 + 10, > >> .vtotal = 1440 + 18 + 10 + 17, > >> - .clock = 69000, > >> + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, > > > > As for pinephone, A64 can’t produce 74.844 MHz precisely, so this will not work. > > > > Better fix is to alter the mode so that clock can be something the only SoC this > > panel is used with can actually produce. > > > > See eg. <https://github.com/megous/linux/commit/dd070679d717e7f34af7558563698240a43981a6> > > which is tested to actually produce 60Hz by measuring the vsync events against > > the CPU timer. > > I did some testing using a 60fps video I produced using the following command: > ffmpeg -f lavfi -i testsrc=duration=10:size=80x50:rate=60 -vf > “drawtext=text=%{n}:fontsize=36:r=60:x=(w-tw)/2: > y=h-(1*lh):fontcolor=white:box=1:boxcolor=0x00000099” test_80x50.mp4 > > This 10-second video shows an increasing number on every frame, which makes it > easy to spot dropped frames by recording the playback with a camera that can > record more than 60fps (I used a 240fps camera). > > When playing back that video with your current drm-6.2 branch I get a steady > 60fps. But applying either your or my patch to mainline, only helps very > little. Frames are being skipped more often than not in both cases. > > Therefore, I need to investigate more and retract the patch for now. > > The other two patches I sent earlier, however, are far more important for > making the pinephone usable on mainline. Mainline sunxi DE2 DRM driver has a bug where it doesn't respect the requirement to use the 50% higher clock for MIPI DSI output. So real refresh rate will be 2/3 the expected one, even if everything else is set correctly. This is not documented in A64 datasheet, but it is documented in one of other Allwinner SoC datasheets that reuse DE2 engine and MIPI DSI interface. So, you need this first: https://github.com/megous/linux/commit/cc3ce397408b597f5cab2c987cd88cce3a8509d3 When this is fixed, it's possible to finetune the panel refresh rate/mode to the actual clock. The values I have sent you the link to are tuned to 60.006 Hz Maybe you'll find some values that will produce 60Hz exactly, but the above is the closest I was able to get to 60Hz. kind regards, o. > Best regards, > Frank > > > > > Your patch will not produce the intended effect. > > > > kind regards, > > o. > > > >> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, > >> .width_mm = 68, > >> .height_mm = 136, > >> – > >> 2.39.1 > >>
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c index 6747ca237ced..cd7d631f7573 100644 --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = { .vsync_start = 1440 + 20, .vsync_end = 1440 + 20 + 4, .vtotal = 1440 + 20 + 4 + 12, - .clock = 75276, + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000, .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, .width_mm = 65, .height_mm = 130, @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = { .vsync_start = 1440 + 18, .vsync_end = 1440 + 18 + 10, .vtotal = 1440 + 18 + 10 + 17, - .clock = 69000, + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, .width_mm = 68, .height_mm = 136,