From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 70B72FBF3; Fri, 22 Dec 2023 09:10:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oltmanns.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oltmanns.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oltmanns.dev header.i=@oltmanns.dev header.b="DlBuv078" Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4SxM2v34f7z9t0p; Fri, 22 Dec 2023 10:10:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1703236231; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ALCq2oz1QBxbdllKqhnSviXLc3yIJ0Q6F604tnrSPGU=; b=DlBuv078ks+xCfMpS4YGEbAyftvJU5MWD2zYGJdt1rHSSvsseWjGZqyfyxz0qMzIFp7XkN 7MUU2ro5XMNQ5MAuN0wsL9qKgfenY7+JteMwB1gARN4sL1QcF25u0jNkdTR2rusDYOrx7V 4DiqEBOgeMLLMjDD1HtfCL8oH630b7js43llHq/bjuPfBZ3bPDtQnX3IYJrTdho3VgMt00 jm3bD/cBQDxQ535aP2tAa6O+IFRr1yH/0XxcnXriJDRhO9rgok3pP+g4ADBfS+QLXeAaTQ M5HPc3RKaCxOwl15RFYLsyJzyP/frT+oRbRYFGVpzW2MvJ+H9DliTCFFbSVf2w== References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev> <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev> <1845418.atdPhlSkOF@jernej-laptop> <875y0sacmz.fsf@oltmanns.dev> From: Frank Oltmanns To: Frank Oltmanns Cc: Jernej =?utf-8?Q?=C5=A0krabec?= , Michael Turquette , Stephen Boyd , Chen-Yu Tsai , Samuel Holland , Guido =?utf-8?Q?G?= =?utf-8?Q?=C3=BCnther?= , Purism Kernel Team , Ondrej Jirman , Neil Armstrong , Jessica Zhang , Sam Ravnborg , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate In-reply-to: <875y0sacmz.fsf@oltmanns.dev> Date: Fri, 22 Dec 2023 10:10:25 +0100 Message-ID: <87v88qk3ge.fsf@oltmanns.dev> Precedence: bulk X-Mailing-List: linux-clk@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2023-12-20 at 19:57:06 +0100, Frank Oltmanns wrote: > Ok, I've done more detailed testing, and it seems this patch results in > lots of dropped frames. I'm sorry for not being more thorough earlier. > I'll do some more testing without this patch and might have to either > remove it from V2 of this series. > > I need to see if the same stability can be achieved when running > PLL-MIPI outside its specied range. I've done some more (load) testing and observing the panel for dropped frames. The conclusion I draw from those results is that this patch isn't necessary for the pinephone. It would be enough to use the correct clock rate based on the existing values [*]: - .clock =3D 69000, + .clock =3D (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, I've asked in the postmarketOS community for a bit more testing. They already have a merge request that contains these changes [2]. This means that we would continue to drive PLL-MIPI outside it's specified range. I have, so far, not experienced any downside of doing so. It seems enough to fix the ratios that are part of the first four patches in this series without introducing a min and max rate. In conclusion, I'll soon (after some more feedback from the fine folks at postmarketOS) submit a V2 that addresses the fixes requested in the first four patches of this series. I'll drop the existing PATCH 5 and replace it with the one I sent in February [1] instead. After that, just for fun, I'll probably look into min_rate and max_rate for nkm clocks and which consequences it has on the pinephone. I might or might not send a follow up series for that. However, if the pinephone runs stable without it, it's not a high priority for me. Best regards, Frank [*] I've already submitted a patch in February '23 [1]. It was of little use back then because the A64's PLL-MIPI clock was not able to run close to that rate. But since kernel 6.6 PLL-MIPI is able to set it's parent rate, so that it can come quite close to the required rate: + Panel requires 74.844 MHz with the current timings. +-> tcon-data-clock rate should be 112.266 MHz (panel*24/4/4). +-> PLL-MIPI rate should be 449.064 MHz (TCON0 * 4) The 6.6 kernel the following rates are possible: + PLL-MIPI: ~448.984615 MHz +-> tcon-data-clock: ~112.246153 +-> panel: ~74.830768 MHz Which leaves us with a vertical refresh rate of ~59.989 Hz, deviating less then 0.2% from the ideal 60Hz. That's probably closer than the accumulated accuracy of all involved components can reliably achieve. I'd say, let's leave it at that. [1]: https://lore.kernel.org/lkml/20230219114553.288057-2-frank@oltmanns.de= v/ [2]: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4645 > > Best regards, > Frank > > On 2023-12-20 at 16:18:49 +0100, Jernej =C5=A0krabec wrote: >> Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a= ): >>> >>> On 2023-12-19 at 18:04:29 +0100, Jernej =C5=A0krabec wrote: >>> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns n= apisal(a): >>> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC. >>> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more >>> >> than 500 MHz. >>> >> >>> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate >>> >> that is high enough to drive PLL-MIPI within its limits. >>> >> >>> >> Signed-off-by: Frank Oltmanns >>> > >>> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have s= et >>> > minimum frequency limit in clock driver. If you add it, clock framewo= rk >>> > should find rate that is high enough and divisible with target rate. >>> >>> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for >>> this panel has to run exactly at 6 * panel clock. Let me start by >>> showing the relevant part of the clock tree (this is on the pinephone >>> after applying the patches): >>> pll-video0 393600000 >>> pll-mipi 500945454 >>> tcon0 500945454 >>> tcon-data-clock 125236363 >>> >>> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit >>> rate [1]. It's a fixed divisor >>> >>> The panel I'm proposing to change is defined as this: >>> >>> static const struct st7703_panel_desc xbd599_desc =3D { >>> .mode =3D &xbd599_mode, >>> .lanes =3D 4, >>> .mode_flags =3D MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PUL= SE, >>> .format =3D MIPI_DSI_FMT_RGB888, >>> .init_sequence =3D xbd599_init_sequence, >>> }; >>> >>> So, we have 24 bpp and 4 lanes. Therefore, the resulting requested >>> tcon-data-clock rate is >>> crtc_clock * 1000 * (24 / 4) / 4 >>> >>> tcon-data-clock therefore requests a parent rate of >>> 4 * (crtc_clock * 1000 * (24 / 4) / 4) >>> >>> The initial 4 is the fixed divisor between tcon0 and tcon-data-clock. >>> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi. >>> >>> Since PLL-MIPI has to run at at least at 500MHz this forces us to have a >>> crtc_clock >=3D 83.333 MHz. The mode I'm prorposing results in a rate of >>> 83.502 MHz. >> >> This is much better explanation why this change is needed. Still, I think >> adding min and max rate to PLL_MIPI would make sense, so proper rates >> are guaranteed. >> >> Anyway, do you know where are all those old values come from? And how did >> you come up with new ones? I guess you can't just simply change timings, >> there are probably some HW limitations? Do you know if BSP kernel support >> this panel and how this situation is solved there? >> >>> >>> If we only changed the constraints on the PLL_MIPI without changing the >>> panel mode, we end up with a mismatch. This, in turn, would result in >>> dropped frames, right? >> >> From what I read, I think frame rate would be higher than 60 fps. What >> exactly would happen depends on the panel. >> >> Best regards, >> Jernej >> >>> >>> Best regards, >>> Frank >>> >>> [1] Source: >>> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/su= n4i_tcon.c#L346 >>> >>> > >>> > Best regards, >>> > Jernej >>> > >>> >> --- >>> >> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++------- >>> >> 1 file changed, 7 insertions(+), 7 deletions(-) >>> >> >>> >> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers= /gpu/drm/panel/panel-sitronix-st7703.c >>> >> index b55bafd1a8be..6886fd7f765e 100644 >>> >> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c >>> >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c >>> >> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 = *ctx) >>> >> >>> >> static const struct drm_display_mode xbd599_mode =3D { >>> >> .hdisplay =3D 720, >>> >> - .hsync_start =3D 720 + 40, >>> >> - .hsync_end =3D 720 + 40 + 40, >>> >> - .htotal =3D 720 + 40 + 40 + 40, >>> >> + .hsync_start =3D 720 + 65, >>> >> + .hsync_end =3D 720 + 65 + 65, >>> >> + .htotal =3D 720 + 65 + 65 + 65, >>> >> .vdisplay =3D 1440, >>> >> - .vsync_start =3D 1440 + 18, >>> >> - .vsync_end =3D 1440 + 18 + 10, >>> >> - .vtotal =3D 1440 + 18 + 10 + 17, >>> >> - .clock =3D 69000, >>> >> + .vsync_start =3D 1440 + 30, >>> >> + .vsync_end =3D 1440 + 30 + 22, >>> >> + .vtotal =3D 1440 + 30 + 22 + 29, >>> >> + .clock =3D (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 = / 1000, >>> >> .flags =3D DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, >>> >> .width_mm =3D 68, >>> >> .height_mm =3D 136, >>> >> >>> >> >>> From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2A32FC41535 for ; Fri, 22 Dec 2023 09:11:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date: In-reply-to:Subject:Cc:To:From:References:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=BL4YWKPHG9iMnazPz4oxljVz3i4OO52kBbOjXqdk8VA=; b=p2Vug8kEAL583HDzEv3Fspl+pj ArWnrjiPoVcWGyqnAD5AyTriSPSP5C5tkTGvxbL3eLCNQKmoScAAYCaGG0CGgf7zGK1th4nw0DFBj Tw1v6IjrqDctiYqvXCOZ1XflyBaMrLOV6ZSsnCcVn5qa7SYrWVMEbqGF/y1qpHYCCby/Uumf2YKBN wJ1xU6apy1ZEJAfSrq9rNjEvFpZHMCtwtT9VgAFy9zeMKN/HjMcDrh4HQyz5LQsS/KrnYqL2GuXRd qYfTZP5E6S9xLiFHpI6taJ7FhGOX2/l+RreVwdsvU8ltm9GCSY0zUvGEhDXBp7JEryAHonjzyK7aw kAXgx8Dg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rGbYH-005Oas-0r; Fri, 22 Dec 2023 09:10:41 +0000 Received: from mout-p-202.mailbox.org ([2001:67c:2050:0:465::202]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rGbYD-005OaJ-1m for linux-arm-kernel@lists.infradead.org; Fri, 22 Dec 2023 09:10:39 +0000 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4SxM2v34f7z9t0p; Fri, 22 Dec 2023 10:10:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1703236231; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ALCq2oz1QBxbdllKqhnSviXLc3yIJ0Q6F604tnrSPGU=; b=DlBuv078ks+xCfMpS4YGEbAyftvJU5MWD2zYGJdt1rHSSvsseWjGZqyfyxz0qMzIFp7XkN 7MUU2ro5XMNQ5MAuN0wsL9qKgfenY7+JteMwB1gARN4sL1QcF25u0jNkdTR2rusDYOrx7V 4DiqEBOgeMLLMjDD1HtfCL8oH630b7js43llHq/bjuPfBZ3bPDtQnX3IYJrTdho3VgMt00 jm3bD/cBQDxQ535aP2tAa6O+IFRr1yH/0XxcnXriJDRhO9rgok3pP+g4ADBfS+QLXeAaTQ M5HPc3RKaCxOwl15RFYLsyJzyP/frT+oRbRYFGVpzW2MvJ+H9DliTCFFbSVf2w== References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev> <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev> <1845418.atdPhlSkOF@jernej-laptop> <875y0sacmz.fsf@oltmanns.dev> From: Frank Oltmanns To: Frank Oltmanns Cc: Jernej =?utf-8?Q?=C5=A0krabec?= , Michael Turquette , Stephen Boyd , Chen-Yu Tsai , Samuel Holland , Guido =?utf-8?Q?G?= =?utf-8?Q?=C3=BCnther?= , Purism Kernel Team , Ondrej Jirman , Neil Armstrong , Jessica Zhang , Sam Ravnborg , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate In-reply-to: <875y0sacmz.fsf@oltmanns.dev> Date: Fri, 22 Dec 2023 10:10:25 +0100 Message-ID: <87v88qk3ge.fsf@oltmanns.dev> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231222_011037_843135_22231680 X-CRM114-Status: GOOD ( 34.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Ck9uIDIwMjMtMTItMjAgYXQgMTk6NTc6MDYgKzAxMDAsIEZyYW5rIE9sdG1hbm5zIDxmcmFua0Bv bHRtYW5ucy5kZXY+IHdyb3RlOgo+IE9rLCBJJ3ZlIGRvbmUgbW9yZSBkZXRhaWxlZCB0ZXN0aW5n LCBhbmQgaXQgc2VlbXMgdGhpcyBwYXRjaCByZXN1bHRzIGluCj4gbG90cyBvZiBkcm9wcGVkIGZy YW1lcy4gSSdtIHNvcnJ5IGZvciBub3QgYmVpbmcgbW9yZSB0aG9yb3VnaCBlYXJsaWVyLgo+IEkn bGwgZG8gc29tZSBtb3JlIHRlc3Rpbmcgd2l0aG91dCB0aGlzIHBhdGNoIGFuZCBtaWdodCBoYXZl IHRvIGVpdGhlcgo+IHJlbW92ZSBpdCBmcm9tIFYyIG9mIHRoaXMgc2VyaWVzLgo+Cj4gSSBuZWVk IHRvIHNlZSBpZiB0aGUgc2FtZSBzdGFiaWxpdHkgY2FuIGJlIGFjaGlldmVkIHdoZW4gcnVubmlu Zwo+IFBMTC1NSVBJIG91dHNpZGUgaXRzIHNwZWNpZWQgcmFuZ2UuCgpJJ3ZlIGRvbmUgc29tZSBt b3JlIChsb2FkKSB0ZXN0aW5nIGFuZCBvYnNlcnZpbmcgdGhlIHBhbmVsIGZvciBkcm9wcGVkCmZy YW1lcy4KClRoZSBjb25jbHVzaW9uIEkgZHJhdyBmcm9tIHRob3NlIHJlc3VsdHMgaXMgdGhhdCB0 aGlzIHBhdGNoIGlzbid0Cm5lY2Vzc2FyeSBmb3IgdGhlIHBpbmVwaG9uZS4gSXQgd291bGQgYmUg ZW5vdWdoIHRvIHVzZSB0aGUgY29ycmVjdCBjbG9jawpyYXRlIGJhc2VkIG9uIHRoZSBleGlzdGlu ZyB2YWx1ZXMgWypdOgotCS5jbG9jawkgICAgID0gNjkwMDAsCisJLmNsb2NrCSAgICAgPSAoNzIw ICsgNDAgKyA0MCArIDQwKSAqICgxNDQwICsgMTggKyAxMCArIDE3KSAqIDYwIC8gMTAwMCwKCkkn dmUgYXNrZWQgaW4gdGhlIHBvc3RtYXJrZXRPUyBjb21tdW5pdHkgZm9yIGEgYml0IG1vcmUgdGVz dGluZy4gVGhleQphbHJlYWR5IGhhdmUgYSBtZXJnZSByZXF1ZXN0IHRoYXQgY29udGFpbnMgdGhl c2UgY2hhbmdlcyBbMl0uCgpUaGlzIG1lYW5zIHRoYXQgd2Ugd291bGQgY29udGludWUgdG8gZHJp dmUgUExMLU1JUEkgb3V0c2lkZSBpdCdzCnNwZWNpZmllZCByYW5nZS4gSSBoYXZlLCBzbyBmYXIs IG5vdCBleHBlcmllbmNlZCBhbnkgZG93bnNpZGUgb2YgZG9pbmcKc28uIEl0IHNlZW1zIGVub3Vn aCB0byBmaXggdGhlIHJhdGlvcyB0aGF0IGFyZSBwYXJ0IG9mIHRoZSBmaXJzdCBmb3VyCnBhdGNo ZXMgaW4gdGhpcyBzZXJpZXMgd2l0aG91dCBpbnRyb2R1Y2luZyBhIG1pbiBhbmQgbWF4IHJhdGUu CgpJbiBjb25jbHVzaW9uLCBJJ2xsIHNvb24gKGFmdGVyIHNvbWUgbW9yZSBmZWVkYmFjayBmcm9t IHRoZSBmaW5lIGZvbGtzCmF0IHBvc3RtYXJrZXRPUykgc3VibWl0IGEgVjIgdGhhdCBhZGRyZXNz ZXMgdGhlIGZpeGVzIHJlcXVlc3RlZCBpbiB0aGUKZmlyc3QgZm91ciBwYXRjaGVzIG9mIHRoaXMg c2VyaWVzLiBJJ2xsIGRyb3AgdGhlIGV4aXN0aW5nIFBBVENIIDUgYW5kCnJlcGxhY2UgaXQgd2l0 aCB0aGUgb25lIEkgc2VudCBpbiBGZWJydWFyeSBbMV0gaW5zdGVhZC4KCkFmdGVyIHRoYXQsIGp1 c3QgZm9yIGZ1biwgSSdsbCBwcm9iYWJseSBsb29rIGludG8gbWluX3JhdGUgYW5kIG1heF9yYXRl CmZvciBua20gY2xvY2tzIGFuZCB3aGljaCBjb25zZXF1ZW5jZXMgaXQgaGFzIG9uIHRoZSBwaW5l cGhvbmUuIEkgbWlnaHQKb3IgbWlnaHQgbm90IHNlbmQgYSBmb2xsb3cgdXAgc2VyaWVzIGZvciB0 aGF0LiBIb3dldmVyLCBpZiB0aGUgcGluZXBob25lCnJ1bnMgc3RhYmxlIHdpdGhvdXQgaXQsIGl0 J3Mgbm90IGEgaGlnaCBwcmlvcml0eSBmb3IgbWUuCgpCZXN0IHJlZ2FyZHMsCiAgRnJhbmsKClsq XSBJJ3ZlIGFscmVhZHkgc3VibWl0dGVkIGEgcGF0Y2ggaW4gRmVicnVhcnkgJzIzIFsxXS4gSXQg d2FzIG9mIGxpdHRsZQogICAgdXNlIGJhY2sgdGhlbiBiZWNhdXNlIHRoZSBBNjQncyBQTEwtTUlQ SSBjbG9jayB3YXMgbm90IGFibGUgdG8gcnVuCiAgICBjbG9zZSB0byB0aGF0IHJhdGUuIEJ1dCBz aW5jZSBrZXJuZWwgNi42IFBMTC1NSVBJIGlzIGFibGUgdG8gc2V0CiAgICBpdCdzIHBhcmVudCBy YXRlLCBzbyB0aGF0IGl0IGNhbiBjb21lIHF1aXRlIGNsb3NlIHRvIHRoZSByZXF1aXJlZAogICAg cmF0ZToKICAgICArIFBhbmVsIHJlcXVpcmVzIDc0Ljg0NCBNSHogd2l0aCB0aGUgY3VycmVudCB0 aW1pbmdzLgogICAgICstPiB0Y29uLWRhdGEtY2xvY2sgcmF0ZSBzaG91bGQgYmUgMTEyLjI2NiBN SHogKHBhbmVsKjI0LzQvNCkuCiAgICAgICstPiBQTEwtTUlQSSByYXRlIHNob3VsZCBiZSA0NDku MDY0IE1IeiAoVENPTjAgKiA0KQoKICAgIFRoZSA2LjYga2VybmVsIHRoZSBmb2xsb3dpbmcgcmF0 ZXMgYXJlIHBvc3NpYmxlOgogICAgICsgUExMLU1JUEk6IH40NDguOTg0NjE1IE1IegogICAgICst PiB0Y29uLWRhdGEtY2xvY2s6IH4xMTIuMjQ2MTUzCiAgICAgICstPiBwYW5lbDogfjc0LjgzMDc2 OCBNSHoKCiAgICBXaGljaCBsZWF2ZXMgdXMgd2l0aCBhIHZlcnRpY2FsIHJlZnJlc2ggcmF0ZSBv ZiB+NTkuOTg5IEh6LAogICAgZGV2aWF0aW5nIGxlc3MgdGhlbiAwLjIlIGZyb20gdGhlIGlkZWFs IDYwSHouIFRoYXQncyBwcm9iYWJseSBjbG9zZXIKICAgIHRoYW4gdGhlIGFjY3VtdWxhdGVkIGFj Y3VyYWN5IG9mIGFsbCBpbnZvbHZlZCBjb21wb25lbnRzIGNhbgogICAgcmVsaWFibHkgYWNoaWV2 ZS4gSSdkIHNheSwgbGV0J3MgbGVhdmUgaXQgYXQgdGhhdC4KClsxXTogaHR0cHM6Ly9sb3JlLmtl cm5lbC5vcmcvbGttbC8yMDIzMDIxOTExNDU1My4yODgwNTctMi1mcmFua0BvbHRtYW5ucy5kZXYv ClsyXTogaHR0cHM6Ly9naXRsYWIuY29tL3Bvc3RtYXJrZXRPUy9wbWFwb3J0cy8tL21lcmdlX3Jl cXVlc3RzLzQ2NDUKPgo+IEJlc3QgcmVnYXJkcywKPiAgIEZyYW5rCj4KPiBPbiAyMDIzLTEyLTIw IGF0IDE2OjE4OjQ5ICswMTAwLCBKZXJuZWogxaBrcmFiZWMgPGplcm5lai5za3JhYmVjQGdtYWls LmNvbT4gd3JvdGU6Cj4+IERuZSBzcmVkYSwgMjAuIGRlY2VtYmVyIDIwMjMgb2IgMDg6MTQ6Mjcg Q0VUIGplIEZyYW5rIE9sdG1hbm5zIG5hcGlzYWwoYSk6Cj4+Pgo+Pj4gT24gMjAyMy0xMi0xOSBh dCAxODowNDoyOSArMDEwMCwgSmVybmVqIMWga3JhYmVjIDxqZXJuZWouc2tyYWJlY0BnbWFpbC5j b20+IHdyb3RlOgo+Pj4gPiBEbmUgcG9uZWRlbGplaywgMTguIGRlY2VtYmVyIDIwMjMgb2IgMTQ6 MzU6MjMgQ0VUIGplIEZyYW5rIE9sdG1hbm5zIG5hcGlzYWwoYSk6Cj4+PiA+PiBUaGlzIHBhbmVs IGlzIHVzZWQgaW4gdGhlIHBpbmVwaG9uZSB0aGF0IHJ1bnMgb24gYSBBbGx3aW5uZXIgQTY0IFNP Qy4KPj4+ID4+IEFjb29yZGluZyB0byBpdCdzIGRhdGFzaGVldCwgdGhlIFNPQyByZXF1aXJlcyBQ TEwtTUlQSSB0byBydW4gYXQgbW9yZQo+Pj4gPj4gdGhhbiA1MDAgTUh6Lgo+Pj4gPj4KPj4+ID4+ IFRoZXJlZm9yZSwgY2hhbmdlIFtodl1zeW5jXyhzdGFydHxlbmQpIHNvIHRoYXQgd2UgcmVhY2gg YSBjbG9jayByYXRlCj4+PiA+PiB0aGF0IGlzIGhpZ2ggZW5vdWdoIHRvIGRyaXZlIFBMTC1NSVBJ IHdpdGhpbiBpdHMgbGltaXRzLgo+Pj4gPj4KPj4+ID4+IFNpZ25lZC1vZmYtYnk6IEZyYW5rIE9s dG1hbm5zIDxmcmFua0BvbHRtYW5ucy5kZXY+Cj4+PiA+Cj4+PiA+IEknbSBub3QgdG9vIHN1cmUg YWJvdXQgdGhpcyBwYXRjaC4gSSBzZWUgdGhhdCBQTExfTUlQSSBkb2Vzbid0IGhhdmUgc2V0Cj4+ PiA+IG1pbmltdW0gZnJlcXVlbmN5IGxpbWl0IGluIGNsb2NrIGRyaXZlci4gSWYgeW91IGFkZCBp dCwgY2xvY2sgZnJhbWV3b3JrCj4+PiA+IHNob3VsZCBmaW5kIHJhdGUgdGhhdCBpcyBoaWdoIGVu b3VnaCBhbmQgZGl2aXNpYmxlIHdpdGggdGFyZ2V0IHJhdGUuCj4+Pgo+Pj4gVGhpcyBvbmUgaXMg cmVhbGx5IGEgdG91Z2ggbnV0LiBVbmZvcnR1bmF0ZWx5LCB0aGUgUExMX01JUEkgY2xvY2sgZm9y Cj4+PiB0aGlzIHBhbmVsIGhhcyB0byBydW4gZXhhY3RseSBhdCA2ICogcGFuZWwgY2xvY2suIExl dCBtZSBzdGFydCBieQo+Pj4gc2hvd2luZyB0aGUgcmVsZXZhbnQgcGFydCBvZiB0aGUgY2xvY2sg dHJlZSAodGhpcyBpcyBvbiB0aGUgcGluZXBob25lCj4+PiBhZnRlciBhcHBseWluZyB0aGUgcGF0 Y2hlcyk6Cj4+PiAgICAgcGxsLXZpZGVvMCAgICAgICAgICAgICAgICAgMzkzNjAwMDAwCj4+PiAg ICAgICAgcGxsLW1pcGkgICAgICAgICAgICAgICAgNTAwOTQ1NDU0Cj4+PiAgICAgICAgICAgdGNv bjAgICAgICAgICAgICAgICAgNTAwOTQ1NDU0Cj4+PiAgICAgICAgICAgICAgdGNvbi1kYXRhLWNs b2NrICAgMTI1MjM2MzYzCj4+Pgo+Pj4gVG8gZWxhYm9yYXRlLCB0Y29uLWRhdGEtY2xvY2sgaGFz IHRvIHJ1biBhdCAxLzQgdGhlIERTSSBwZXItbGFuZSBiaXQKPj4+IHJhdGUgWzFdLiBJdCdzIGEg Zml4ZWQgZGl2aXNvcgo+Pj4KPj4+IFRoZSBwYW5lbCBJJ20gcHJvcG9zaW5nIHRvIGNoYW5nZSBp cyBkZWZpbmVkIGFzIHRoaXM6Cj4+Pgo+Pj4gICAgIHN0YXRpYyBjb25zdCBzdHJ1Y3Qgc3Q3NzAz X3BhbmVsX2Rlc2MgeGJkNTk5X2Rlc2MgPSB7Cj4+PiAgICAgCS5tb2RlID0gJnhiZDU5OV9tb2Rl LAo+Pj4gICAgIAkubGFuZXMgPSA0LAo+Pj4gICAgIAkubW9kZV9mbGFncyA9IE1JUElfRFNJX01P REVfVklERU8gfCBNSVBJX0RTSV9NT0RFX1ZJREVPX1NZTkNfUFVMU0UsCj4+PiAgICAgCS5mb3Jt YXQgPSBNSVBJX0RTSV9GTVRfUkdCODg4LAo+Pj4gICAgIAkuaW5pdF9zZXF1ZW5jZSA9IHhiZDU5 OV9pbml0X3NlcXVlbmNlLAo+Pj4gICAgIH07Cj4+Pgo+Pj4gU28sIHdlIGhhdmUgMjQgYnBwIGFu ZCA0IGxhbmVzLiBUaGVyZWZvcmUsIHRoZSByZXN1bHRpbmcgcmVxdWVzdGVkCj4+PiB0Y29uLWRh dGEtY2xvY2sgcmF0ZSBpcwo+Pj4gICAgIGNydGNfY2xvY2sgKiAxMDAwICogKDI0IC8gNCkgLyA0 Cj4+Pgo+Pj4gdGNvbi1kYXRhLWNsb2NrIHRoZXJlZm9yZSByZXF1ZXN0cyBhIHBhcmVudCByYXRl IG9mCj4+PiAgICAgNCAqIChjcnRjX2Nsb2NrICogMTAwMCAqICgyNCAvIDQpIC8gNCkKPj4+Cj4+ PiBUaGUgaW5pdGlhbCA0IGlzIHRoZSBmaXhlZCBkaXZpc29yIGJldHdlZW4gdGNvbjAgYW5kIHRj b24tZGF0YS1jbG9jay4KPj4+IFNpbmNlIHRjb24wIGlzIGEgY2N1X211eCwgdGhlIHJhdGUgb2Yg dGNvbjAgZXF1YWxzIHRoZSByYXRlIG9mIHBsbC1taXBpLgo+Pj4KPj4+IFNpbmNlIFBMTC1NSVBJ IGhhcyB0byBydW4gYXQgYXQgbGVhc3QgYXQgNTAwTUh6IHRoaXMgZm9yY2VzIHVzIHRvIGhhdmUg YQo+Pj4gY3J0Y19jbG9jayA+PSA4My4zMzMgTUh6LiBUaGUgbW9kZSBJJ20gcHJvcnBvc2luZyBy ZXN1bHRzIGluIGEgcmF0ZSBvZgo+Pj4gODMuNTAyIE1Iei4KPj4KPj4gVGhpcyBpcyBtdWNoIGJl dHRlciBleHBsYW5hdGlvbiB3aHkgdGhpcyBjaGFuZ2UgaXMgbmVlZGVkLiBTdGlsbCwgSSB0aGlu awo+PiBhZGRpbmcgbWluIGFuZCBtYXggcmF0ZSB0byBQTExfTUlQSSB3b3VsZCBtYWtlIHNlbnNl LCBzbyBwcm9wZXIgcmF0ZXMKPj4gYXJlIGd1YXJhbnRlZWQuCj4+Cj4+IEFueXdheSwgZG8geW91 IGtub3cgd2hlcmUgYXJlIGFsbCB0aG9zZSBvbGQgdmFsdWVzIGNvbWUgZnJvbT8gQW5kIGhvdyBk aWQKPj4geW91IGNvbWUgdXAgd2l0aCBuZXcgb25lcz8gSSBndWVzcyB5b3UgY2FuJ3QganVzdCBz aW1wbHkgY2hhbmdlIHRpbWluZ3MsCj4+IHRoZXJlIGFyZSBwcm9iYWJseSBzb21lIEhXIGxpbWl0 YXRpb25zPyBEbyB5b3Uga25vdyBpZiBCU1Aga2VybmVsIHN1cHBvcnQKPj4gdGhpcyBwYW5lbCBh bmQgaG93IHRoaXMgc2l0dWF0aW9uIGlzIHNvbHZlZCB0aGVyZT8KPj4KPj4+Cj4+PiBJZiB3ZSBv bmx5IGNoYW5nZWQgdGhlIGNvbnN0cmFpbnRzIG9uIHRoZSBQTExfTUlQSSB3aXRob3V0IGNoYW5n aW5nIHRoZQo+Pj4gcGFuZWwgbW9kZSwgd2UgZW5kIHVwIHdpdGggYSBtaXNtYXRjaC4gVGhpcywg aW4gdHVybiwgd291bGQgcmVzdWx0IGluCj4+PiBkcm9wcGVkIGZyYW1lcywgcmlnaHQ/Cj4+Cj4+ IEZyb20gd2hhdCBJIHJlYWQsIEkgdGhpbmsgZnJhbWUgcmF0ZSB3b3VsZCBiZSBoaWdoZXIgdGhh biA2MCBmcHMuIFdoYXQKPj4gZXhhY3RseSB3b3VsZCBoYXBwZW4gZGVwZW5kcyBvbiB0aGUgcGFu ZWwuCj4+Cj4+IEJlc3QgcmVnYXJkcywKPj4gSmVybmVqCj4+Cj4+Pgo+Pj4gQmVzdCByZWdhcmRz LAo+Pj4gICBGcmFuawo+Pj4KPj4+IFsxXSBTb3VyY2U6Cj4+PiBodHRwczovL2VsaXhpci5ib290 bGluLmNvbS9saW51eC92Ni42Ljcvc291cmNlL2RyaXZlcnMvZ3B1L2RybS9zdW40aS9zdW40aV90 Y29uLmMjTDM0Ngo+Pj4KPj4+ID4KPj4+ID4gQmVzdCByZWdhcmRzLAo+Pj4gPiBKZXJuZWoKPj4+ ID4KPj4+ID4+IC0tLQo+Pj4gPj4gIGRyaXZlcnMvZ3B1L2RybS9wYW5lbC9wYW5lbC1zaXRyb25p eC1zdDc3MDMuYyB8IDE0ICsrKysrKystLS0tLS0tCj4+PiA+PiAgMSBmaWxlIGNoYW5nZWQsIDcg aW5zZXJ0aW9ucygrKSwgNyBkZWxldGlvbnMoLSkKPj4+ID4+Cj4+PiA+PiBkaWZmIC0tZ2l0IGEv ZHJpdmVycy9ncHUvZHJtL3BhbmVsL3BhbmVsLXNpdHJvbml4LXN0NzcwMy5jIGIvZHJpdmVycy9n cHUvZHJtL3BhbmVsL3BhbmVsLXNpdHJvbml4LXN0NzcwMy5jCj4+PiA+PiBpbmRleCBiNTViYWZk MWE4YmUuLjY4ODZmZDdmNzY1ZSAxMDA2NDQKPj4+ID4+IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9w YW5lbC9wYW5lbC1zaXRyb25peC1zdDc3MDMuYwo+Pj4gPj4gKysrIGIvZHJpdmVycy9ncHUvZHJt L3BhbmVsL3BhbmVsLXNpdHJvbml4LXN0NzcwMy5jCj4+PiA+PiBAQCAtMzIwLDE0ICszMjAsMTQg QEAgc3RhdGljIGludCB4YmQ1OTlfaW5pdF9zZXF1ZW5jZShzdHJ1Y3Qgc3Q3NzAzICpjdHgpCj4+ PiA+Pgo+Pj4gPj4gIHN0YXRpYyBjb25zdCBzdHJ1Y3QgZHJtX2Rpc3BsYXlfbW9kZSB4YmQ1OTlf bW9kZSA9IHsKPj4+ID4+ICAJLmhkaXNwbGF5ICAgID0gNzIwLAo+Pj4gPj4gLQkuaHN5bmNfc3Rh cnQgPSA3MjAgKyA0MCwKPj4+ID4+IC0JLmhzeW5jX2VuZCAgID0gNzIwICsgNDAgKyA0MCwKPj4+ ID4+IC0JLmh0b3RhbAkgICAgID0gNzIwICsgNDAgKyA0MCArIDQwLAo+Pj4gPj4gKwkuaHN5bmNf c3RhcnQgPSA3MjAgKyA2NSwKPj4+ID4+ICsJLmhzeW5jX2VuZCAgID0gNzIwICsgNjUgKyA2NSwK Pj4+ID4+ICsJLmh0b3RhbCAgICAgID0gNzIwICsgNjUgKyA2NSArIDY1LAo+Pj4gPj4gIAkudmRp c3BsYXkgICAgPSAxNDQwLAo+Pj4gPj4gLQkudnN5bmNfc3RhcnQgPSAxNDQwICsgMTgsCj4+PiA+ PiAtCS52c3luY19lbmQgICA9IDE0NDAgKyAxOCArIDEwLAo+Pj4gPj4gLQkudnRvdGFsCSAgICAg PSAxNDQwICsgMTggKyAxMCArIDE3LAo+Pj4gPj4gLQkuY2xvY2sJICAgICA9IDY5MDAwLAo+Pj4g Pj4gKwkudnN5bmNfc3RhcnQgPSAxNDQwICsgMzAsCj4+PiA+PiArCS52c3luY19lbmQgICA9IDE0 NDAgKyAzMCArIDIyLAo+Pj4gPj4gKwkudnRvdGFsCSAgICAgPSAxNDQwICsgMzAgKyAyMiArIDI5 LAo+Pj4gPj4gKwkuY2xvY2sJICAgICA9ICg3MjAgKyA2NSArIDY1ICsgNjUpICogKDE0NDAgKyAz MCArIDIyICsgMjkpICogNjAgLyAxMDAwLAo+Pj4gPj4gIAkuZmxhZ3MJICAgICA9IERSTV9NT0RF X0ZMQUdfTkhTWU5DIHwgRFJNX01PREVfRkxBR19OVlNZTkMsCj4+PiA+PiAgCS53aWR0aF9tbSAg ICA9IDY4LAo+Pj4gPj4gIAkuaGVpZ2h0X21tICAgPSAxMzYsCj4+PiA+Pgo+Pj4gPj4KPj4+Cgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy bmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5FCAEC41535 for ; Fri, 22 Dec 2023 09:10:36 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CA2A010E765; Fri, 22 Dec 2023 09:10:35 +0000 (UTC) Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by gabe.freedesktop.org (Postfix) with ESMTPS id F2B0710E765 for ; Fri, 22 Dec 2023 09:10:34 +0000 (UTC) Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4SxM2v34f7z9t0p; Fri, 22 Dec 2023 10:10:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1703236231; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ALCq2oz1QBxbdllKqhnSviXLc3yIJ0Q6F604tnrSPGU=; b=DlBuv078ks+xCfMpS4YGEbAyftvJU5MWD2zYGJdt1rHSSvsseWjGZqyfyxz0qMzIFp7XkN 7MUU2ro5XMNQ5MAuN0wsL9qKgfenY7+JteMwB1gARN4sL1QcF25u0jNkdTR2rusDYOrx7V 4DiqEBOgeMLLMjDD1HtfCL8oH630b7js43llHq/bjuPfBZ3bPDtQnX3IYJrTdho3VgMt00 jm3bD/cBQDxQ535aP2tAa6O+IFRr1yH/0XxcnXriJDRhO9rgok3pP+g4ADBfS+QLXeAaTQ M5HPc3RKaCxOwl15RFYLsyJzyP/frT+oRbRYFGVpzW2MvJ+H9DliTCFFbSVf2w== References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev> <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev> <1845418.atdPhlSkOF@jernej-laptop> <875y0sacmz.fsf@oltmanns.dev> From: Frank Oltmanns To: Frank Oltmanns Subject: Re: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate In-reply-to: <875y0sacmz.fsf@oltmanns.dev> Date: Fri, 22 Dec 2023 10:10:25 +0100 Message-ID: <87v88qk3ge.fsf@oltmanns.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org, Neil Armstrong , Purism Kernel Team , Samuel Holland , Stephen Boyd , David Airlie , Michael Turquette , linux-kernel@vger.kernel.org, Jernej =?utf-8?Q?=C5=A0krabec?= , linux-clk@vger.kernel.org, linux-sunxi@lists.linux.dev, Chen-Yu Tsai , Ondrej Jirman , Maxime Ripard , Thomas Zimmermann , Jessica Zhang , Sam Ravnborg , Guido =?utf-8?Q?G?= =?utf-8?Q?=C3=BCnther?= , linux-arm-kernel@lists.infradead.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2023-12-20 at 19:57:06 +0100, Frank Oltmanns wrote: > Ok, I've done more detailed testing, and it seems this patch results in > lots of dropped frames. I'm sorry for not being more thorough earlier. > I'll do some more testing without this patch and might have to either > remove it from V2 of this series. > > I need to see if the same stability can be achieved when running > PLL-MIPI outside its specied range. I've done some more (load) testing and observing the panel for dropped frames. The conclusion I draw from those results is that this patch isn't necessary for the pinephone. It would be enough to use the correct clock rate based on the existing values [*]: - .clock =3D 69000, + .clock =3D (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000, I've asked in the postmarketOS community for a bit more testing. They already have a merge request that contains these changes [2]. This means that we would continue to drive PLL-MIPI outside it's specified range. I have, so far, not experienced any downside of doing so. It seems enough to fix the ratios that are part of the first four patches in this series without introducing a min and max rate. In conclusion, I'll soon (after some more feedback from the fine folks at postmarketOS) submit a V2 that addresses the fixes requested in the first four patches of this series. I'll drop the existing PATCH 5 and replace it with the one I sent in February [1] instead. After that, just for fun, I'll probably look into min_rate and max_rate for nkm clocks and which consequences it has on the pinephone. I might or might not send a follow up series for that. However, if the pinephone runs stable without it, it's not a high priority for me. Best regards, Frank [*] I've already submitted a patch in February '23 [1]. It was of little use back then because the A64's PLL-MIPI clock was not able to run close to that rate. But since kernel 6.6 PLL-MIPI is able to set it's parent rate, so that it can come quite close to the required rate: + Panel requires 74.844 MHz with the current timings. +-> tcon-data-clock rate should be 112.266 MHz (panel*24/4/4). +-> PLL-MIPI rate should be 449.064 MHz (TCON0 * 4) The 6.6 kernel the following rates are possible: + PLL-MIPI: ~448.984615 MHz +-> tcon-data-clock: ~112.246153 +-> panel: ~74.830768 MHz Which leaves us with a vertical refresh rate of ~59.989 Hz, deviating less then 0.2% from the ideal 60Hz. That's probably closer than the accumulated accuracy of all involved components can reliably achieve. I'd say, let's leave it at that. [1]: https://lore.kernel.org/lkml/20230219114553.288057-2-frank@oltmanns.de= v/ [2]: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4645 > > Best regards, > Frank > > On 2023-12-20 at 16:18:49 +0100, Jernej =C5=A0krabec wrote: >> Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a= ): >>> >>> On 2023-12-19 at 18:04:29 +0100, Jernej =C5=A0krabec wrote: >>> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns n= apisal(a): >>> >> This panel is used in the pinephone that runs on a Allwinner A64 SOC. >>> >> Acoording to it's datasheet, the SOC requires PLL-MIPI to run at more >>> >> than 500 MHz. >>> >> >>> >> Therefore, change [hv]sync_(start|end) so that we reach a clock rate >>> >> that is high enough to drive PLL-MIPI within its limits. >>> >> >>> >> Signed-off-by: Frank Oltmanns >>> > >>> > I'm not too sure about this patch. I see that PLL_MIPI doesn't have s= et >>> > minimum frequency limit in clock driver. If you add it, clock framewo= rk >>> > should find rate that is high enough and divisible with target rate. >>> >>> This one is really a tough nut. Unfortunately, the PLL_MIPI clock for >>> this panel has to run exactly at 6 * panel clock. Let me start by >>> showing the relevant part of the clock tree (this is on the pinephone >>> after applying the patches): >>> pll-video0 393600000 >>> pll-mipi 500945454 >>> tcon0 500945454 >>> tcon-data-clock 125236363 >>> >>> To elaborate, tcon-data-clock has to run at 1/4 the DSI per-lane bit >>> rate [1]. It's a fixed divisor >>> >>> The panel I'm proposing to change is defined as this: >>> >>> static const struct st7703_panel_desc xbd599_desc =3D { >>> .mode =3D &xbd599_mode, >>> .lanes =3D 4, >>> .mode_flags =3D MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PUL= SE, >>> .format =3D MIPI_DSI_FMT_RGB888, >>> .init_sequence =3D xbd599_init_sequence, >>> }; >>> >>> So, we have 24 bpp and 4 lanes. Therefore, the resulting requested >>> tcon-data-clock rate is >>> crtc_clock * 1000 * (24 / 4) / 4 >>> >>> tcon-data-clock therefore requests a parent rate of >>> 4 * (crtc_clock * 1000 * (24 / 4) / 4) >>> >>> The initial 4 is the fixed divisor between tcon0 and tcon-data-clock. >>> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi. >>> >>> Since PLL-MIPI has to run at at least at 500MHz this forces us to have a >>> crtc_clock >=3D 83.333 MHz. The mode I'm prorposing results in a rate of >>> 83.502 MHz. >> >> This is much better explanation why this change is needed. Still, I think >> adding min and max rate to PLL_MIPI would make sense, so proper rates >> are guaranteed. >> >> Anyway, do you know where are all those old values come from? And how did >> you come up with new ones? I guess you can't just simply change timings, >> there are probably some HW limitations? Do you know if BSP kernel support >> this panel and how this situation is solved there? >> >>> >>> If we only changed the constraints on the PLL_MIPI without changing the >>> panel mode, we end up with a mismatch. This, in turn, would result in >>> dropped frames, right? >> >> From what I read, I think frame rate would be higher than 60 fps. What >> exactly would happen depends on the panel. >> >> Best regards, >> Jernej >> >>> >>> Best regards, >>> Frank >>> >>> [1] Source: >>> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/su= n4i_tcon.c#L346 >>> >>> > >>> > Best regards, >>> > Jernej >>> > >>> >> --- >>> >> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 14 +++++++------- >>> >> 1 file changed, 7 insertions(+), 7 deletions(-) >>> >> >>> >> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers= /gpu/drm/panel/panel-sitronix-st7703.c >>> >> index b55bafd1a8be..6886fd7f765e 100644 >>> >> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c >>> >> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c >>> >> @@ -320,14 +320,14 @@ static int xbd599_init_sequence(struct st7703 = *ctx) >>> >> >>> >> static const struct drm_display_mode xbd599_mode =3D { >>> >> .hdisplay =3D 720, >>> >> - .hsync_start =3D 720 + 40, >>> >> - .hsync_end =3D 720 + 40 + 40, >>> >> - .htotal =3D 720 + 40 + 40 + 40, >>> >> + .hsync_start =3D 720 + 65, >>> >> + .hsync_end =3D 720 + 65 + 65, >>> >> + .htotal =3D 720 + 65 + 65 + 65, >>> >> .vdisplay =3D 1440, >>> >> - .vsync_start =3D 1440 + 18, >>> >> - .vsync_end =3D 1440 + 18 + 10, >>> >> - .vtotal =3D 1440 + 18 + 10 + 17, >>> >> - .clock =3D 69000, >>> >> + .vsync_start =3D 1440 + 30, >>> >> + .vsync_end =3D 1440 + 30 + 22, >>> >> + .vtotal =3D 1440 + 30 + 22 + 29, >>> >> + .clock =3D (720 + 65 + 65 + 65) * (1440 + 30 + 22 + 29) * 60 = / 1000, >>> >> .flags =3D DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, >>> >> .width_mm =3D 68, >>> >> .height_mm =3D 136, >>> >> >>> >> >>>