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 C502DDDBB; Sat, 30 Dec 2023 21:17:29 +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="Sm3iHXtN" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (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 4T2Znr2Cjnz9scM; Sat, 30 Dec 2023 22:17:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1703971040; 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=EqzpSggOCyXix/RyQdbwO3KPIBKLdQSHS6acVQjzt6c=; b=Sm3iHXtNAXh9K/xf42tiU1rN0I+mCEy7Yh5xJB7lDG45dqj4W4QsJ7Q/8b/Z+/TQTOU6uL xJzOGVp79vCiwI3fCWWUQt/IPOXhjto4X8+hF37c+grkV4kAMOOZCqwAm8Y2mnb6XP8d+z sWkJ/CZAPewrist1vQJCgjN00S26rMZvLb5LeIiZJjWtBqHgUUHVHpw7yMy3M68bcYolTL gB1ZRwWHrAaIUagoQw6KafgX2nljdrhZMH1SDYB7NJw92QYz8Zqoq2tQpdiAVY4bpGg21o 78kBpVZuMnESIZSP+DJR/X8wjBz5hKJDNFFo2xDZWzRFFpOp7sxQMs3olLm4lg== References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev> <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev> <1845418.atdPhlSkOF@jernej-laptop> From: Frank Oltmanns To: Jernej =?utf-8?Q?=C5=A0krabec?= Cc: Michael Turquette , Stephen Boyd , Chen-Yu Tsai , Samuel Holland , Guido =?utf-8?Q?G=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, Icenowy Zheng Subject: Re: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate In-reply-to: <1845418.atdPhlSkOF@jernej-laptop> Date: Sat, 30 Dec 2023 22:17:06 +0100 Message-ID: <87wmsvo0fh.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 X-Rspamd-Queue-Id: 4T2Znr2Cjnz9scM 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 na= pisal(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 set >> > minimum frequency limit in clock driver. If you add it, clock framework >> > 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_PULS= E, >> .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. Okay, I'll include min and max rate in V2, because you're right that it's the sane thing to do and actually it wasn't too much work. I (and others) do experience crashes if pll-mipi is driven below the 500 MHz mark, so let's fix this once and for all. > Anyway, do you know where are all those old values come from? I've done some digging on lore and the values were originally submitted by Icenowy Zheng as part of a series to support the pinephone's LCD [1]. There has been some refactoring after this initial submission and Ondrej Jirman took over. But the values are still the ones submitted by Icenowy, so I've added her to CC. I couldn't find any documentation for this specific panel. > And how did > you come up with new ones? Trial and no error. :) No, really, it was just a lucky guess. I know nothing about LCD panels, so I only looked at the original values: .htotal =3D 720 + 40 + 40 + 40, .vtotal =3D 1440 + 18 + 10 + 17, I thought, what if every time I increase a horizontal value by 2, I increase a vertical value by 1 (very roughly). So I ended up with: .htotal =3D 720 + 65 + 65 + 65, .vtotal =3D 1440 + 30 + 22 + 29, So, in conclusion, I've increased each of the horizontal values by 25 and each of the vertical values by 12. Then I just tried out these new values, and the world didn't end. :) If this is stupid, please somebody let me know. I (and at least one postmarket OS tester) have been daily driving the panel with these values for about a week now. I've checked the panel's refresh rate with the following test setup: - I created a 60 fps video that shows the current frame number in each frame. The video is 10 seconds (600 frames) long. [2] - I played that video on my pinephone using vlc. [3] - I recorded the playback with a Google Pixel 5 phone at 1/8 slow motion (240 fps). - I converted the video into individual pictures [4], resized the pictures to 10% [5], and finally - after deleting some superfluous pictures at the beginning and end - I created one big collage out of these [6]. I've uploaded the video[7], resulting collage [8] and the individual pictures [9]. In the resulting picture you can see that in the beginning frame 2 is missing and frame 136 is only barely visible because it is stuck too long on frame 135. Other than that, I think this looks pretty good. > 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? I'm not aware of any BSP kernel that supports this kernel. >> 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. To give this a fair comparison, I tested with the original timings but with correcting the panel's clock rate of 74844 kHZ instead of 69000 kHz as discussed elsewhere in this thread [10] and pll-mipi running at 500MHz (because that's really a must to run the pinephone in a stable manner). I used the same procedure as described above. Again, I've uploaded the resulting video [11], collage [12] and the individual files [13]. Here, the being stuck happens much more often, e.g. frames 23, 31, 40, 49, 58, 66 etc. So, I think, in order to have a better user experience, I think it's a good idea to update the XBD599 panel with the new values I proposed in this patch. Best regards, Frank [1]: https://lore.kernel.org/all/20200311162936.221613-1-icenowy@aosc.io/ [2]: ffmpeg -f lavfi -i testsrc=3Dduration=3D10:size=3D80x50:rate=3D60 -vf \ "drawtext=3Dtext=3D%{n}:fontsize=3D36:r=3D60:x=3D(w-tw)/2: y=3Dh-(1*lh):= fontcolor=3Dwhite:box=3D1:boxcolor=3D0x00000099"\ test_80x50.mp4 [3]: cvlc test_80x50.mp4 --fullscreen --play-and-exit [4]: ffmpeg -i video_from_pixel_phone.mp4 -vsync vfr output_%04d.jpg [5]: mogrify -resize 10% output_*.jpg [6]: montage output_*.jpg -tile 20x -geometry +0+0 \ verify_panel_65_65_65_30_22_29_83502.jpg [7]: https://share.mailbox.org/ajax/share/0a471a7205211949ad7067d5211945719= 84a15d1613d74be/1/8/Njg/NjgvMzE [8]: https://share.mailbox.org/ajax/share/0741f90808f2df4e7d1e5078f2df43cfa= e732189f27e75e3/1/8/Njg/NjgvMzI [9]: https://share.mailbox.org/ajax/share/0471bc0706bfee4e4e1a0086bfee40ecb= a2123a14c9b8d4d/1/8/Njg/NjgvMzA [10]: https://lore.kernel.org/all/87v88qk3ge.fsf@oltmanns.dev/ [11]: https://share.mailbox.org/ajax/share/036036d00eac574e3f02adfeac5741dd= a88105026a1221f4/1/8/Njg/NjgvMzQ [12]: https://share.mailbox.org/ajax/share/05f6d3e905e30058566cfe65e300486a= a936122f2414639a/1/8/Njg/NjgvMzU [13]: https://share.mailbox.org/ajax/share/0cf25a810cce2357c62468ecce234681= a4e8e674d38d02cd/1/8/Njg/NjgvMzM > > Best regards, > Jernej > >> >> Best regards, >> Frank >> >> [1] Source: >> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/sun= 4i_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 51769C46CD2 for ; Sat, 30 Dec 2023 21:18:12 +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=f74mMXZIAnwcqE6H1epc24bTIS7NTOML/Aakp+IaoKM=; b=C3xlOnu0S74NpDE+Xie2t0J51O QMC4bJ0sOU2AWHZEn9XQ955SA4BAHEQc25q9sSPPuX/CN87ZM6+qCwBh7xc30YO8kg0lvSe6HGSZW BvX6WQBspJtDSkgkFp7oaum5+TaiOMJv0ndDF7g3dr5cW6Uqw0I0EjlzUupZ7S4WCPlD7OogcEHQG GvfsX4Ui0jz+iP32XY3MpwrTsmSwUjLt7LniX7HhhBR6d7zzLsgeJIPiVHhEzyxFMEjvBCWNXpK8b q5QIvA69PknP84Kqlvqczc6I6EIKYlJaEvP3bIUSvHLBgECQGf8HuPTnUbn+Fbv9ETUTzqrPovhGd 1On2rEKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rJgiE-003S7q-0M; Sat, 30 Dec 2023 21:17:42 +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 1rJgi9-003S5v-31 for linux-arm-kernel@lists.infradead.org; Sat, 30 Dec 2023 21:17:40 +0000 Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (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 4T2Znr2Cjnz9scM; Sat, 30 Dec 2023 22:17:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1703971040; 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=EqzpSggOCyXix/RyQdbwO3KPIBKLdQSHS6acVQjzt6c=; b=Sm3iHXtNAXh9K/xf42tiU1rN0I+mCEy7Yh5xJB7lDG45dqj4W4QsJ7Q/8b/Z+/TQTOU6uL xJzOGVp79vCiwI3fCWWUQt/IPOXhjto4X8+hF37c+grkV4kAMOOZCqwAm8Y2mnb6XP8d+z sWkJ/CZAPewrist1vQJCgjN00S26rMZvLb5LeIiZJjWtBqHgUUHVHpw7yMy3M68bcYolTL gB1ZRwWHrAaIUagoQw6KafgX2nljdrhZMH1SDYB7NJw92QYz8Zqoq2tQpdiAVY4bpGg21o 78kBpVZuMnESIZSP+DJR/X8wjBz5hKJDNFFo2xDZWzRFFpOp7sxQMs3olLm4lg== References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev> <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev> <1845418.atdPhlSkOF@jernej-laptop> From: Frank Oltmanns To: Jernej =?utf-8?Q?=C5=A0krabec?= Cc: Michael Turquette , Stephen Boyd , Chen-Yu Tsai , Samuel Holland , Guido =?utf-8?Q?G=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, Icenowy Zheng Subject: Re: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate In-reply-to: <1845418.atdPhlSkOF@jernej-laptop> Date: Sat, 30 Dec 2023 22:17:06 +0100 Message-ID: <87wmsvo0fh.fsf@oltmanns.dev> MIME-Version: 1.0 X-Rspamd-Queue-Id: 4T2Znr2Cjnz9scM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231230_131738_140639_8900250D X-CRM114-Status: GOOD ( 41.93 ) 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 Ck9uIDIwMjMtMTItMjAgYXQgMTY6MTg6NDkgKzAxMDAsIEplcm5laiDFoGtyYWJlYyA8amVybmVq LnNrcmFiZWNAZ21haWwuY29tPiB3cm90ZToKPiBEbmUgc3JlZGEsIDIwLiBkZWNlbWJlciAyMDIz IG9iIDA4OjE0OjI3IENFVCBqZSBGcmFuayBPbHRtYW5ucyBuYXBpc2FsKGEpOgo+Pgo+PiBPbiAy MDIzLTEyLTE5IGF0IDE4OjA0OjI5ICswMTAwLCBKZXJuZWogxaBrcmFiZWMgPGplcm5lai5za3Jh YmVjQGdtYWlsLmNvbT4gd3JvdGU6Cj4+ID4gRG5lIHBvbmVkZWxqZWssIDE4LiBkZWNlbWJlciAy MDIzIG9iIDE0OjM1OjIzIENFVCBqZSBGcmFuayBPbHRtYW5ucyBuYXBpc2FsKGEpOgo+PiA+PiBU aGlzIHBhbmVsIGlzIHVzZWQgaW4gdGhlIHBpbmVwaG9uZSB0aGF0IHJ1bnMgb24gYSBBbGx3aW5u ZXIgQTY0IFNPQy4KPj4gPj4gQWNvb3JkaW5nIHRvIGl0J3MgZGF0YXNoZWV0LCB0aGUgU09DIHJl cXVpcmVzIFBMTC1NSVBJIHRvIHJ1biBhdCBtb3JlCj4+ID4+IHRoYW4gNTAwIE1Iei4KPj4gPj4K Pj4gPj4gVGhlcmVmb3JlLCBjaGFuZ2UgW2h2XXN5bmNfKHN0YXJ0fGVuZCkgc28gdGhhdCB3ZSBy ZWFjaCBhIGNsb2NrIHJhdGUKPj4gPj4gdGhhdCBpcyBoaWdoIGVub3VnaCB0byBkcml2ZSBQTEwt TUlQSSB3aXRoaW4gaXRzIGxpbWl0cy4KPj4gPj4KPj4gPj4gU2lnbmVkLW9mZi1ieTogRnJhbmsg T2x0bWFubnMgPGZyYW5rQG9sdG1hbm5zLmRldj4KPj4gPgo+PiA+IEknbSBub3QgdG9vIHN1cmUg YWJvdXQgdGhpcyBwYXRjaC4gSSBzZWUgdGhhdCBQTExfTUlQSSBkb2Vzbid0IGhhdmUgc2V0Cj4+ ID4gbWluaW11bSBmcmVxdWVuY3kgbGltaXQgaW4gY2xvY2sgZHJpdmVyLiBJZiB5b3UgYWRkIGl0 LCBjbG9jayBmcmFtZXdvcmsKPj4gPiBzaG91bGQgZmluZCByYXRlIHRoYXQgaXMgaGlnaCBlbm91 Z2ggYW5kIGRpdmlzaWJsZSB3aXRoIHRhcmdldCByYXRlLgo+Pgo+PiBUaGlzIG9uZSBpcyByZWFs bHkgYSB0b3VnaCBudXQuIFVuZm9ydHVuYXRlbHksIHRoZSBQTExfTUlQSSBjbG9jayBmb3IKPj4g dGhpcyBwYW5lbCBoYXMgdG8gcnVuIGV4YWN0bHkgYXQgNiAqIHBhbmVsIGNsb2NrLiBMZXQgbWUg c3RhcnQgYnkKPj4gc2hvd2luZyB0aGUgcmVsZXZhbnQgcGFydCBvZiB0aGUgY2xvY2sgdHJlZSAo dGhpcyBpcyBvbiB0aGUgcGluZXBob25lCj4+IGFmdGVyIGFwcGx5aW5nIHRoZSBwYXRjaGVzKToK Pj4gICAgIHBsbC12aWRlbzAgICAgICAgICAgICAgICAgIDM5MzYwMDAwMAo+PiAgICAgICAgcGxs LW1pcGkgICAgICAgICAgICAgICAgNTAwOTQ1NDU0Cj4+ICAgICAgICAgICB0Y29uMCAgICAgICAg ICAgICAgICA1MDA5NDU0NTQKPj4gICAgICAgICAgICAgIHRjb24tZGF0YS1jbG9jayAgIDEyNTIz NjM2Mwo+Pgo+PiBUbyBlbGFib3JhdGUsIHRjb24tZGF0YS1jbG9jayBoYXMgdG8gcnVuIGF0IDEv NCB0aGUgRFNJIHBlci1sYW5lIGJpdAo+PiByYXRlIFsxXS4gSXQncyBhIGZpeGVkIGRpdmlzb3IK Pj4KPj4gVGhlIHBhbmVsIEknbSBwcm9wb3NpbmcgdG8gY2hhbmdlIGlzIGRlZmluZWQgYXMgdGhp czoKPj4KPj4gICAgIHN0YXRpYyBjb25zdCBzdHJ1Y3Qgc3Q3NzAzX3BhbmVsX2Rlc2MgeGJkNTk5 X2Rlc2MgPSB7Cj4+ICAgICAJLm1vZGUgPSAmeGJkNTk5X21vZGUsCj4+ICAgICAJLmxhbmVzID0g NCwKPj4gICAgIAkubW9kZV9mbGFncyA9IE1JUElfRFNJX01PREVfVklERU8gfCBNSVBJX0RTSV9N T0RFX1ZJREVPX1NZTkNfUFVMU0UsCj4+ICAgICAJLmZvcm1hdCA9IE1JUElfRFNJX0ZNVF9SR0I4 ODgsCj4+ICAgICAJLmluaXRfc2VxdWVuY2UgPSB4YmQ1OTlfaW5pdF9zZXF1ZW5jZSwKPj4gICAg IH07Cj4+Cj4+IFNvLCB3ZSBoYXZlIDI0IGJwcCBhbmQgNCBsYW5lcy4gVGhlcmVmb3JlLCB0aGUg cmVzdWx0aW5nIHJlcXVlc3RlZAo+PiB0Y29uLWRhdGEtY2xvY2sgcmF0ZSBpcwo+PiAgICAgY3J0 Y19jbG9jayAqIDEwMDAgKiAoMjQgLyA0KSAvIDQKPj4KPj4gdGNvbi1kYXRhLWNsb2NrIHRoZXJl Zm9yZSByZXF1ZXN0cyBhIHBhcmVudCByYXRlIG9mCj4+ICAgICA0ICogKGNydGNfY2xvY2sgKiAx MDAwICogKDI0IC8gNCkgLyA0KQo+Pgo+PiBUaGUgaW5pdGlhbCA0IGlzIHRoZSBmaXhlZCBkaXZp c29yIGJldHdlZW4gdGNvbjAgYW5kIHRjb24tZGF0YS1jbG9jay4KPj4gU2luY2UgdGNvbjAgaXMg YSBjY3VfbXV4LCB0aGUgcmF0ZSBvZiB0Y29uMCBlcXVhbHMgdGhlIHJhdGUgb2YgcGxsLW1pcGku Cj4+Cj4+IFNpbmNlIFBMTC1NSVBJIGhhcyB0byBydW4gYXQgYXQgbGVhc3QgYXQgNTAwTUh6IHRo aXMgZm9yY2VzIHVzIHRvIGhhdmUgYQo+PiBjcnRjX2Nsb2NrID49IDgzLjMzMyBNSHouIFRoZSBt b2RlIEknbSBwcm9ycG9zaW5nIHJlc3VsdHMgaW4gYSByYXRlIG9mCj4+IDgzLjUwMiBNSHouCj4K PiBUaGlzIGlzIG11Y2ggYmV0dGVyIGV4cGxhbmF0aW9uIHdoeSB0aGlzIGNoYW5nZSBpcyBuZWVk ZWQuIFN0aWxsLCBJIHRoaW5rCj4gYWRkaW5nIG1pbiBhbmQgbWF4IHJhdGUgdG8gUExMX01JUEkg d291bGQgbWFrZSBzZW5zZSwgc28gcHJvcGVyIHJhdGVzCj4gYXJlIGd1YXJhbnRlZWQuCgpPa2F5 LCBJJ2xsIGluY2x1ZGUgbWluIGFuZCBtYXggcmF0ZSBpbiBWMiwgYmVjYXVzZSB5b3UncmUgcmln aHQgdGhhdAppdCdzIHRoZSBzYW5lIHRoaW5nIHRvIGRvIGFuZCBhY3R1YWxseSBpdCB3YXNuJ3Qg dG9vIG11Y2ggd29yay4gSSAoYW5kCm90aGVycykgZG8gZXhwZXJpZW5jZSBjcmFzaGVzIGlmIHBs bC1taXBpIGlzIGRyaXZlbiBiZWxvdyB0aGUgNTAwIE1IegptYXJrLCBzbyBsZXQncyBmaXggdGhp cyBvbmNlIGFuZCBmb3IgYWxsLgoKPiBBbnl3YXksIGRvIHlvdSBrbm93IHdoZXJlIGFyZSBhbGwg dGhvc2Ugb2xkIHZhbHVlcyBjb21lIGZyb20/CgpJJ3ZlIGRvbmUgc29tZSBkaWdnaW5nIG9uIGxv cmUgYW5kIHRoZSB2YWx1ZXMgd2VyZSBvcmlnaW5hbGx5IHN1Ym1pdHRlZApieSBJY2Vub3d5IFpo ZW5nIGFzIHBhcnQgb2YgYSBzZXJpZXMgdG8gc3VwcG9ydCB0aGUgcGluZXBob25lJ3MgTENEIFsx XS4KVGhlcmUgaGFzIGJlZW4gc29tZSByZWZhY3RvcmluZyBhZnRlciB0aGlzIGluaXRpYWwgc3Vi bWlzc2lvbiBhbmQgT25kcmVqCkppcm1hbiB0b29rIG92ZXIuIEJ1dCB0aGUgdmFsdWVzIGFyZSBz dGlsbCB0aGUgb25lcyBzdWJtaXR0ZWQgYnkKSWNlbm93eSwgc28gSSd2ZSBhZGRlZCBoZXIgdG8g Q0MuIEkgY291bGRuJ3QgZmluZCBhbnkgZG9jdW1lbnRhdGlvbiBmb3IKdGhpcyBzcGVjaWZpYyBw YW5lbC4KCj4gQW5kIGhvdyBkaWQKPiB5b3UgY29tZSB1cCB3aXRoIG5ldyBvbmVzPwoKVHJpYWwg YW5kIG5vIGVycm9yLiA6KQoKTm8sIHJlYWxseSwgaXQgd2FzIGp1c3QgYSBsdWNreSBndWVzcy4g SSBrbm93IG5vdGhpbmcgYWJvdXQgTENEIHBhbmVscywKc28gSSBvbmx5IGxvb2tlZCBhdCB0aGUg b3JpZ2luYWwgdmFsdWVzOgouaHRvdGFsID0gIDcyMCArIDQwICsgNDAgKyA0MCwKLnZ0b3RhbCA9 IDE0NDAgKyAxOCArIDEwICsgMTcsCgpJIHRob3VnaHQsIHdoYXQgaWYgZXZlcnkgdGltZSBJIGlu Y3JlYXNlIGEgaG9yaXpvbnRhbCB2YWx1ZSBieSAyLCBJCmluY3JlYXNlIGEgdmVydGljYWwgdmFs dWUgYnkgMSAodmVyeSByb3VnaGx5KS4KClNvIEkgZW5kZWQgdXAgd2l0aDoKLmh0b3RhbCA9ICA3 MjAgKyA2NSArIDY1ICsgNjUsCi52dG90YWwgPSAxNDQwICsgMzAgKyAyMiArIDI5LAoKU28sIGlu IGNvbmNsdXNpb24sIEkndmUgaW5jcmVhc2VkIGVhY2ggb2YgdGhlIGhvcml6b250YWwgdmFsdWVz IGJ5IDI1CmFuZCBlYWNoIG9mIHRoZSB2ZXJ0aWNhbCB2YWx1ZXMgYnkgMTIuIFRoZW4gSSBqdXN0 IHRyaWVkIG91dCB0aGVzZSBuZXcKdmFsdWVzLCBhbmQgdGhlIHdvcmxkIGRpZG4ndCBlbmQuIDop CgpJZiB0aGlzIGlzIHN0dXBpZCwgcGxlYXNlIHNvbWVib2R5IGxldCBtZSBrbm93LgoKSSAoYW5k IGF0IGxlYXN0IG9uZSBwb3N0bWFya2V0IE9TIHRlc3RlcikgaGF2ZSBiZWVuIGRhaWx5IGRyaXZp bmcgdGhlCnBhbmVsIHdpdGggdGhlc2UgdmFsdWVzIGZvciBhYm91dCBhIHdlZWsgbm93LgoKSSd2 ZSBjaGVja2VkIHRoZSBwYW5lbCdzIHJlZnJlc2ggcmF0ZSB3aXRoIHRoZSBmb2xsb3dpbmcgdGVz dCBzZXR1cDoKIC0gSSBjcmVhdGVkIGEgNjAgZnBzIHZpZGVvIHRoYXQgc2hvd3MgdGhlIGN1cnJl bnQgZnJhbWUgbnVtYmVyIGluIGVhY2gKICAgZnJhbWUuIFRoZSB2aWRlbyBpcyAxMCBzZWNvbmRz ICg2MDAgZnJhbWVzKSBsb25nLiBbMl0KIC0gSSBwbGF5ZWQgdGhhdCB2aWRlbyBvbiBteSBwaW5l cGhvbmUgdXNpbmcgdmxjLiBbM10KIC0gSSByZWNvcmRlZCB0aGUgcGxheWJhY2sgd2l0aCBhIEdv b2dsZSBQaXhlbCA1IHBob25lIGF0IDEvOCBzbG93CiAgIG1vdGlvbiAoMjQwIGZwcykuCiAtIEkg Y29udmVydGVkIHRoZSB2aWRlbyBpbnRvIGluZGl2aWR1YWwgcGljdHVyZXMgWzRdLCByZXNpemVk CiAgIHRoZSBwaWN0dXJlcyB0byAxMCUgWzVdLCBhbmQgZmluYWxseSAtIGFmdGVyIGRlbGV0aW5n IHNvbWUgc3VwZXJmbHVvdXMKICAgcGljdHVyZXMgYXQgdGhlIGJlZ2lubmluZyBhbmQgZW5kIC0g SSBjcmVhdGVkIG9uZSBiaWcgY29sbGFnZSBvdXQgb2YKICAgdGhlc2UgWzZdLgoKSSd2ZSB1cGxv YWRlZCB0aGUgdmlkZW9bN10sIHJlc3VsdGluZyBjb2xsYWdlIFs4XSBhbmQgdGhlIGluZGl2aWR1 YWwKcGljdHVyZXMgWzldLgoKSW4gdGhlIHJlc3VsdGluZyBwaWN0dXJlIHlvdSBjYW4gc2VlIHRo YXQgaW4gdGhlIGJlZ2lubmluZyBmcmFtZSAyIGlzCm1pc3NpbmcgYW5kIGZyYW1lIDEzNiBpcyBv bmx5IGJhcmVseSB2aXNpYmxlIGJlY2F1c2UgaXQgaXMgc3R1Y2sgdG9vCmxvbmcgb24gZnJhbWUg MTM1LiBPdGhlciB0aGFuIHRoYXQsIEkgdGhpbmsgdGhpcyBsb29rcyBwcmV0dHkgZ29vZC4KCj4g SSBndWVzcyB5b3UgY2FuJ3QganVzdCBzaW1wbHkgY2hhbmdlIHRpbWluZ3MsCj4gdGhlcmUgYXJl IHByb2JhYmx5IHNvbWUgSFcgbGltaXRhdGlvbnM/IERvIHlvdSBrbm93IGlmIEJTUCBrZXJuZWwg c3VwcG9ydAo+IHRoaXMgcGFuZWwgYW5kIGhvdyB0aGlzIHNpdHVhdGlvbiBpcyBzb2x2ZWQgdGhl cmU/CgpJJ20gbm90IGF3YXJlIG9mIGFueSBCU1Aga2VybmVsIHRoYXQgc3VwcG9ydHMgdGhpcyBr ZXJuZWwuCgo+PiBJZiB3ZSBvbmx5IGNoYW5nZWQgdGhlIGNvbnN0cmFpbnRzIG9uIHRoZSBQTExf TUlQSSB3aXRob3V0IGNoYW5naW5nIHRoZQo+PiBwYW5lbCBtb2RlLCB3ZSBlbmQgdXAgd2l0aCBh IG1pc21hdGNoLiBUaGlzLCBpbiB0dXJuLCB3b3VsZCByZXN1bHQgaW4KPj4gZHJvcHBlZCBmcmFt ZXMsIHJpZ2h0Pwo+Cj4gRnJvbSB3aGF0IEkgcmVhZCwgSSB0aGluayBmcmFtZSByYXRlIHdvdWxk IGJlIGhpZ2hlciB0aGFuIDYwIGZwcy4gV2hhdAo+IGV4YWN0bHkgd291bGQgaGFwcGVuIGRlcGVu ZHMgb24gdGhlIHBhbmVsLgoKVG8gZ2l2ZSB0aGlzIGEgZmFpciBjb21wYXJpc29uLCBJIHRlc3Rl ZCB3aXRoIHRoZSBvcmlnaW5hbCB0aW1pbmdzIGJ1dAp3aXRoIGNvcnJlY3RpbmcgdGhlIHBhbmVs J3MgY2xvY2sgcmF0ZSBvZiA3NDg0NCBrSFogaW5zdGVhZCBvZiA2OTAwMCBrSHoKYXMgZGlzY3Vz c2VkIGVsc2V3aGVyZSBpbiB0aGlzIHRocmVhZCBbMTBdIGFuZCBwbGwtbWlwaSBydW5uaW5nIGF0 CjUwME1IeiAoYmVjYXVzZSB0aGF0J3MgcmVhbGx5IGEgbXVzdCB0byBydW4gdGhlIHBpbmVwaG9u ZSBpbiBhIHN0YWJsZQptYW5uZXIpLiBJIHVzZWQgdGhlIHNhbWUgcHJvY2VkdXJlIGFzIGRlc2Ny aWJlZCBhYm92ZS4gQWdhaW4sIEkndmUKdXBsb2FkZWQgdGhlIHJlc3VsdGluZyB2aWRlbyBbMTFd LCBjb2xsYWdlIFsxMl0gYW5kIHRoZSBpbmRpdmlkdWFsIGZpbGVzClsxM10uCgpIZXJlLCB0aGUg YmVpbmcgc3R1Y2sgaGFwcGVucyBtdWNoIG1vcmUgb2Z0ZW4sIGUuZy4gZnJhbWVzIDIzLCAzMSwg NDAsCjQ5LCA1OCwgNjYgZXRjLgoKU28sIEkgdGhpbmssIGluIG9yZGVyIHRvIGhhdmUgYSBiZXR0 ZXIgdXNlciBleHBlcmllbmNlLCBJIHRoaW5rIGl0J3MgYQpnb29kIGlkZWEgdG8gdXBkYXRlIHRo ZSBYQkQ1OTkgcGFuZWwgd2l0aCB0aGUgbmV3IHZhbHVlcyBJIHByb3Bvc2VkIGluCnRoaXMgcGF0 Y2guCgpCZXN0IHJlZ2FyZHMsCiAgRnJhbmsKClsxXTogaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcv YWxsLzIwMjAwMzExMTYyOTM2LjIyMTYxMy0xLWljZW5vd3lAYW9zYy5pby8KWzJdOiBmZm1wZWcg LWYgbGF2ZmkgLWkgdGVzdHNyYz1kdXJhdGlvbj0xMDpzaXplPTgweDUwOnJhdGU9NjAgLXZmIFwK ICAgImRyYXd0ZXh0PXRleHQ9JXtufTpmb250c2l6ZT0zNjpyPTYwOng9KHctdHcpLzI6IHk9aC0o MSpsaCk6Zm9udGNvbG9yPXdoaXRlOmJveD0xOmJveGNvbG9yPTB4MDAwMDAwOTkiXAogICB0ZXN0 XzgweDUwLm1wNApbM106IGN2bGMgdGVzdF84MHg1MC5tcDQgIC0tZnVsbHNjcmVlbiAtLXBsYXkt YW5kLWV4aXQKWzRdOiBmZm1wZWcgLWkgdmlkZW9fZnJvbV9waXhlbF9waG9uZS5tcDQgLXZzeW5j IHZmciBvdXRwdXRfJTA0ZC5qcGcKWzVdOiBtb2dyaWZ5IC1yZXNpemUgMTAlIG91dHB1dF8qLmpw ZwpbNl06IG1vbnRhZ2Ugb3V0cHV0XyouanBnIC10aWxlIDIweCAtZ2VvbWV0cnkgKzArMCBcCiAg ICAgIHZlcmlmeV9wYW5lbF82NV82NV82NV8zMF8yMl8yOV84MzUwMi5qcGcKWzddOiBodHRwczov L3NoYXJlLm1haWxib3gub3JnL2FqYXgvc2hhcmUvMGE0NzFhNzIwNTIxMTk0OWFkNzA2N2Q1MjEx OTQ1NzE5ODRhMTVkMTYxM2Q3NGJlLzEvOC9OamcvTmpndk16RQpbOF06IGh0dHBzOi8vc2hhcmUu bWFpbGJveC5vcmcvYWpheC9zaGFyZS8wNzQxZjkwODA4ZjJkZjRlN2QxZTUwNzhmMmRmNDNjZmFl NzMyMTg5ZjI3ZTc1ZTMvMS84L05qZy9Oamd2TXpJCls5XTogaHR0cHM6Ly9zaGFyZS5tYWlsYm94 Lm9yZy9hamF4L3NoYXJlLzA0NzFiYzA3MDZiZmVlNGU0ZTFhMDA4NmJmZWU0MGVjYmEyMTIzYTE0 YzliOGQ0ZC8xLzgvTmpnL05qZ3ZNekEKWzEwXTogaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvYWxs Lzg3djg4cWszZ2UuZnNmQG9sdG1hbm5zLmRldi8KWzExXTogaHR0cHM6Ly9zaGFyZS5tYWlsYm94 Lm9yZy9hamF4L3NoYXJlLzAzNjAzNmQwMGVhYzU3NGUzZjAyYWRmZWFjNTc0MWRkYTg4MTA1MDI2 YTEyMjFmNC8xLzgvTmpnL05qZ3ZNelEKWzEyXTogaHR0cHM6Ly9zaGFyZS5tYWlsYm94Lm9yZy9h amF4L3NoYXJlLzA1ZjZkM2U5MDVlMzAwNTg1NjZjZmU2NWUzMDA0ODZhYTkzNjEyMmYyNDE0NjM5 YS8xLzgvTmpnL05qZ3ZNelUKWzEzXTogaHR0cHM6Ly9zaGFyZS5tYWlsYm94Lm9yZy9hamF4L3No YXJlLzBjZjI1YTgxMGNjZTIzNTdjNjI0NjhlY2NlMjM0NjgxYTRlOGU2NzRkMzhkMDJjZC8xLzgv TmpnL05qZ3ZNek0KCj4KPiBCZXN0IHJlZ2FyZHMsCj4gSmVybmVqCj4KPj4KPj4gQmVzdCByZWdh cmRzLAo+PiAgIEZyYW5rCj4+Cj4+IFsxXSBTb3VyY2U6Cj4+IGh0dHBzOi8vZWxpeGlyLmJvb3Rs aW4uY29tL2xpbnV4L3Y2LjYuNy9zb3VyY2UvZHJpdmVycy9ncHUvZHJtL3N1bjRpL3N1bjRpX3Rj b24uYyNMMzQ2Cj4+Cj4+ID4KPj4gPiBCZXN0IHJlZ2FyZHMsCj4+ID4gSmVybmVqCj4+ID4KPj4g Pj4gLS0tCj4+ID4+ICBkcml2ZXJzL2dwdS9kcm0vcGFuZWwvcGFuZWwtc2l0cm9uaXgtc3Q3NzAz LmMgfCAxNCArKysrKysrLS0tLS0tLQo+PiA+PiAgMSBmaWxlIGNoYW5nZWQsIDcgaW5zZXJ0aW9u cygrKSwgNyBkZWxldGlvbnMoLSkKPj4gPj4KPj4gPj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1 L2RybS9wYW5lbC9wYW5lbC1zaXRyb25peC1zdDc3MDMuYyBiL2RyaXZlcnMvZ3B1L2RybS9wYW5l bC9wYW5lbC1zaXRyb25peC1zdDc3MDMuYwo+PiA+PiBpbmRleCBiNTViYWZkMWE4YmUuLjY4ODZm ZDdmNzY1ZSAxMDA2NDQKPj4gPj4gLS0tIGEvZHJpdmVycy9ncHUvZHJtL3BhbmVsL3BhbmVsLXNp dHJvbml4LXN0NzcwMy5jCj4+ID4+ICsrKyBiL2RyaXZlcnMvZ3B1L2RybS9wYW5lbC9wYW5lbC1z aXRyb25peC1zdDc3MDMuYwo+PiA+PiBAQCAtMzIwLDE0ICszMjAsMTQgQEAgc3RhdGljIGludCB4 YmQ1OTlfaW5pdF9zZXF1ZW5jZShzdHJ1Y3Qgc3Q3NzAzICpjdHgpCj4+ID4+Cj4+ID4+ICBzdGF0 aWMgY29uc3Qgc3RydWN0IGRybV9kaXNwbGF5X21vZGUgeGJkNTk5X21vZGUgPSB7Cj4+ID4+ICAJ LmhkaXNwbGF5ICAgID0gNzIwLAo+PiA+PiAtCS5oc3luY19zdGFydCA9IDcyMCArIDQwLAo+PiA+ PiAtCS5oc3luY19lbmQgICA9IDcyMCArIDQwICsgNDAsCj4+ID4+IC0JLmh0b3RhbAkgICAgID0g NzIwICsgNDAgKyA0MCArIDQwLAo+PiA+PiArCS5oc3luY19zdGFydCA9IDcyMCArIDY1LAo+PiA+ PiArCS5oc3luY19lbmQgICA9IDcyMCArIDY1ICsgNjUsCj4+ID4+ICsJLmh0b3RhbCAgICAgID0g NzIwICsgNjUgKyA2NSArIDY1LAo+PiA+PiAgCS52ZGlzcGxheSAgICA9IDE0NDAsCj4+ID4+IC0J LnZzeW5jX3N0YXJ0ID0gMTQ0MCArIDE4LAo+PiA+PiAtCS52c3luY19lbmQgICA9IDE0NDAgKyAx OCArIDEwLAo+PiA+PiAtCS52dG90YWwJICAgICA9IDE0NDAgKyAxOCArIDEwICsgMTcsCj4+ID4+ IC0JLmNsb2NrCSAgICAgPSA2OTAwMCwKPj4gPj4gKwkudnN5bmNfc3RhcnQgPSAxNDQwICsgMzAs Cj4+ID4+ICsJLnZzeW5jX2VuZCAgID0gMTQ0MCArIDMwICsgMjIsCj4+ID4+ICsJLnZ0b3RhbAkg ICAgID0gMTQ0MCArIDMwICsgMjIgKyAyOSwKPj4gPj4gKwkuY2xvY2sJICAgICA9ICg3MjAgKyA2 NSArIDY1ICsgNjUpICogKDE0NDAgKyAzMCArIDIyICsgMjkpICogNjAgLyAxMDAwLAo+PiA+PiAg CS5mbGFncwkgICAgID0gRFJNX01PREVfRkxBR19OSFNZTkMgfCBEUk1fTU9ERV9GTEFHX05WU1lO QywKPj4gPj4gIAkud2lkdGhfbW0gICAgPSA2OCwKPj4gPj4gIAkuaGVpZ2h0X21tICAgPSAxMzYs Cj4+ID4+Cj4+ID4+Cj4+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxp c3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9saW51eC1hcm0ta2VybmVsCg== 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 7BA4CC46CD2 for ; Sat, 30 Dec 2023 21:17:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B809910E045; Sat, 30 Dec 2023 21:17:24 +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 0EB5A10E045 for ; Sat, 30 Dec 2023 21:17:23 +0000 (UTC) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (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 4T2Znr2Cjnz9scM; Sat, 30 Dec 2023 22:17:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1703971040; 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=EqzpSggOCyXix/RyQdbwO3KPIBKLdQSHS6acVQjzt6c=; b=Sm3iHXtNAXh9K/xf42tiU1rN0I+mCEy7Yh5xJB7lDG45dqj4W4QsJ7Q/8b/Z+/TQTOU6uL xJzOGVp79vCiwI3fCWWUQt/IPOXhjto4X8+hF37c+grkV4kAMOOZCqwAm8Y2mnb6XP8d+z sWkJ/CZAPewrist1vQJCgjN00S26rMZvLb5LeIiZJjWtBqHgUUHVHpw7yMy3M68bcYolTL gB1ZRwWHrAaIUagoQw6KafgX2nljdrhZMH1SDYB7NJw92QYz8Zqoq2tQpdiAVY4bpGg21o 78kBpVZuMnESIZSP+DJR/X8wjBz5hKJDNFFo2xDZWzRFFpOp7sxQMs3olLm4lg== References: <20231218-pinephone-pll-fixes-v1-0-e238b6ed6dc1@oltmanns.dev> <10386431.nUPlyArG6x@jernej-laptop> <87edfh9ud8.fsf@oltmanns.dev> <1845418.atdPhlSkOF@jernej-laptop> From: Frank Oltmanns To: Jernej =?utf-8?Q?=C5=A0krabec?= Subject: Re: [PATCH 5/5] drm/panel: st7703: Drive XBD599 panel at higher clock rate In-reply-to: <1845418.atdPhlSkOF@jernej-laptop> Date: Sat, 30 Dec 2023 22:17:06 +0100 Message-ID: <87wmsvo0fh.fsf@oltmanns.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T2Znr2Cjnz9scM 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: Neil Armstrong , Purism Kernel Team , Samuel Holland , Stephen Boyd , David Airlie , Michael Turquette , linux-kernel@vger.kernel.org, Maxime Ripard , linux-clk@vger.kernel.org, linux-sunxi@lists.linux.dev, Chen-Yu Tsai , Ondrej Jirman , dri-devel@lists.freedesktop.org, Thomas Zimmermann , Jessica Zhang , Sam Ravnborg , Guido =?utf-8?Q?G=C3=BCnther?= , linux-arm-kernel@lists.infradead.org, Icenowy Zheng Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 na= pisal(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 set >> > minimum frequency limit in clock driver. If you add it, clock framework >> > 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_PULS= E, >> .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. Okay, I'll include min and max rate in V2, because you're right that it's the sane thing to do and actually it wasn't too much work. I (and others) do experience crashes if pll-mipi is driven below the 500 MHz mark, so let's fix this once and for all. > Anyway, do you know where are all those old values come from? I've done some digging on lore and the values were originally submitted by Icenowy Zheng as part of a series to support the pinephone's LCD [1]. There has been some refactoring after this initial submission and Ondrej Jirman took over. But the values are still the ones submitted by Icenowy, so I've added her to CC. I couldn't find any documentation for this specific panel. > And how did > you come up with new ones? Trial and no error. :) No, really, it was just a lucky guess. I know nothing about LCD panels, so I only looked at the original values: .htotal =3D 720 + 40 + 40 + 40, .vtotal =3D 1440 + 18 + 10 + 17, I thought, what if every time I increase a horizontal value by 2, I increase a vertical value by 1 (very roughly). So I ended up with: .htotal =3D 720 + 65 + 65 + 65, .vtotal =3D 1440 + 30 + 22 + 29, So, in conclusion, I've increased each of the horizontal values by 25 and each of the vertical values by 12. Then I just tried out these new values, and the world didn't end. :) If this is stupid, please somebody let me know. I (and at least one postmarket OS tester) have been daily driving the panel with these values for about a week now. I've checked the panel's refresh rate with the following test setup: - I created a 60 fps video that shows the current frame number in each frame. The video is 10 seconds (600 frames) long. [2] - I played that video on my pinephone using vlc. [3] - I recorded the playback with a Google Pixel 5 phone at 1/8 slow motion (240 fps). - I converted the video into individual pictures [4], resized the pictures to 10% [5], and finally - after deleting some superfluous pictures at the beginning and end - I created one big collage out of these [6]. I've uploaded the video[7], resulting collage [8] and the individual pictures [9]. In the resulting picture you can see that in the beginning frame 2 is missing and frame 136 is only barely visible because it is stuck too long on frame 135. Other than that, I think this looks pretty good. > 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? I'm not aware of any BSP kernel that supports this kernel. >> 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. To give this a fair comparison, I tested with the original timings but with correcting the panel's clock rate of 74844 kHZ instead of 69000 kHz as discussed elsewhere in this thread [10] and pll-mipi running at 500MHz (because that's really a must to run the pinephone in a stable manner). I used the same procedure as described above. Again, I've uploaded the resulting video [11], collage [12] and the individual files [13]. Here, the being stuck happens much more often, e.g. frames 23, 31, 40, 49, 58, 66 etc. So, I think, in order to have a better user experience, I think it's a good idea to update the XBD599 panel with the new values I proposed in this patch. Best regards, Frank [1]: https://lore.kernel.org/all/20200311162936.221613-1-icenowy@aosc.io/ [2]: ffmpeg -f lavfi -i testsrc=3Dduration=3D10:size=3D80x50:rate=3D60 -vf \ "drawtext=3Dtext=3D%{n}:fontsize=3D36:r=3D60:x=3D(w-tw)/2: y=3Dh-(1*lh):= fontcolor=3Dwhite:box=3D1:boxcolor=3D0x00000099"\ test_80x50.mp4 [3]: cvlc test_80x50.mp4 --fullscreen --play-and-exit [4]: ffmpeg -i video_from_pixel_phone.mp4 -vsync vfr output_%04d.jpg [5]: mogrify -resize 10% output_*.jpg [6]: montage output_*.jpg -tile 20x -geometry +0+0 \ verify_panel_65_65_65_30_22_29_83502.jpg [7]: https://share.mailbox.org/ajax/share/0a471a7205211949ad7067d5211945719= 84a15d1613d74be/1/8/Njg/NjgvMzE [8]: https://share.mailbox.org/ajax/share/0741f90808f2df4e7d1e5078f2df43cfa= e732189f27e75e3/1/8/Njg/NjgvMzI [9]: https://share.mailbox.org/ajax/share/0471bc0706bfee4e4e1a0086bfee40ecb= a2123a14c9b8d4d/1/8/Njg/NjgvMzA [10]: https://lore.kernel.org/all/87v88qk3ge.fsf@oltmanns.dev/ [11]: https://share.mailbox.org/ajax/share/036036d00eac574e3f02adfeac5741dd= a88105026a1221f4/1/8/Njg/NjgvMzQ [12]: https://share.mailbox.org/ajax/share/05f6d3e905e30058566cfe65e300486a= a936122f2414639a/1/8/Njg/NjgvMzU [13]: https://share.mailbox.org/ajax/share/0cf25a810cce2357c62468ecce234681= a4e8e674d38d02cd/1/8/Njg/NjgvMzM > > Best regards, > Jernej > >> >> Best regards, >> Frank >> >> [1] Source: >> https://elixir.bootlin.com/linux/v6.6.7/source/drivers/gpu/drm/sun4i/sun= 4i_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, >> >> >> >> >>