From: Frank Oltmanns <frank@oltmanns.dev>
To: "Guido Günther" <agx@sigxcpu.org>, "Ondřej Jirman" <megous@megous.com>
Cc: Purism Kernel Team <kernel@puri.sm>,
Thierry Reding <thierry.reding@gmail.com>,
Sam Ravnborg <sam@ravnborg.org>, David Airlie <airlied@gmail.com>,
Daniel Vetter <daniel@ffwll.ch>,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] drm/panel: st7703: Fix vertical refresh rate of XBD599
Date: Sun, 26 Feb 2023 16:17:32 +0100 [thread overview]
Message-ID: <87zg90e6s5.fsf@oltmanns.dev> (raw)
In-Reply-To: <20230219123542.yxb5ixe424ig6ofv@core>
[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]
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
>>
next prev parent reply other threads:[~2023-02-26 16:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-19 11:45 [PATCH 0/1] " Frank Oltmanns
2023-02-19 11:45 ` [PATCH 1/1] " Frank Oltmanns
2023-02-19 12:00 ` Guido Günther
2023-02-19 12:35 ` Ondřej Jirman
2023-02-20 7:40 ` Frank Oltmanns
2023-02-26 15:17 ` Frank Oltmanns [this message]
2023-02-26 17:17 ` Ondřej Jirman
2023-02-26 16:54 ` Slade Watkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zg90e6s5.fsf@oltmanns.dev \
--to=frank@oltmanns.dev \
--cc=agx@sigxcpu.org \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@puri.sm \
--cc=linux-kernel@vger.kernel.org \
--cc=megous@megous.com \
--cc=sam@ravnborg.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome