From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH v5 1/6] drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math. Date: Fri, 04 Aug 2017 14:15:56 -0700 Message-ID: <87r2wrm3ub.fsf@eliezer.anholt.net> References: <20170718210510.12229-1-eric@anholt.net> <20170804105304.68e3b02a@bbrezillon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2116939337==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id 447276E147 for ; Fri, 4 Aug 2017 21:16:15 +0000 (UTC) In-Reply-To: <20170804105304.68e3b02a@bbrezillon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Boris Brezillon Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Thierry Reding , Laurent Pinchart List-Id: dri-devel@lists.freedesktop.org --===============2116939337== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Boris Brezillon writes: > On Tue, 18 Jul 2017 14:05:05 -0700 > Eric Anholt wrote: > >> The incoming mode might have a missing vrefresh field if it came from >> drmModeSetCrtc(), which the kernel is supposed to calculate using >> drm_mode_vrefresh(). We could either use that or the adjusted_mode's >> original vrefresh value. >>=20 >> However, we can maintain a more exact vrefresh value (not just the >> integer approximation), by scaling by the ratio of our clocks. >>=20 >> v2: Use math suggested by Andrzej Hajda instead. >>=20 >> Signed-off-by: Eric Anholt >> --- >> drivers/gpu/drm/vc4/vc4_dsi.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >>=20 >> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi= .c >> index 629d372633e6..57213f4e3c72 100644 >> --- a/drivers/gpu/drm/vc4/vc4_dsi.c >> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c >> @@ -866,7 +866,8 @@ static bool vc4_dsi_encoder_mode_fixup(struct drm_en= coder *encoder, >> adjusted_mode->clock =3D pixel_clock_hz / 1000 + 1; >>=20=20 >> /* Given the new pixel clock, adjust HFP to keep vrefresh the same. */ >> - adjusted_mode->htotal =3D pixel_clock_hz / (mode->vrefresh * mode->vto= tal); >> + adjusted_mode->htotal =3D (pixel_clock_hz / 1000 * mode->htotal / >> + mode->clock); > > Hm, I'm not sure I understand this. Shouldn't we have something like: > > adjusted_mode->htotal =3D (adjusted_mode->clock * mode->htotal) / > mode->clock; > > Is there a reason for doing '+ 1' when you calculate the adjusted > pixel clock rate but not here? We're actually expecting to get within epsilon of pixel_clock_hz, but we have to bump our clk_set_rate() to a higher value because the clock driver will give you a bad divider if you ask for anything less than the rate it can provide. How about I don't increment the adjusted_mode->clock (since it'll be userspace visible I think), and instead move that and the "Round up" comment to the clk_set_rate()? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlmE5A0ACgkQtdYpNtH8 nuiM9xAAjIsQ3BqfHYn756V0ev5TeZlhz0Szi7gs0R7lEONekJeyfqObSn4cUCdW cmVOp4EGDDbkbSRIwoDrPHzpK5JBCEvAcioxHdmrWi1oln5oIYxreCjxFiw54CkQ oAZUOI1OjFcb8nRw182oHiC9EI0v9PkDRTqeWY2bqBu4lcrqrIlngKZNiheB0B0L bH8gtApYlwKBc0i2OFSC2M2EI0YH4lReoEPwn86c9E5taR5Gw91zqQFOzNrKDqD7 /940ryVaRZxAnSX0oTSzt5DSXy8HB8DbGk7JKl0pdtGy3Hs3w7WbxdAr/1n/lcpq nJoXIwTWiOQOxhWA5BoDuN0vRNAEpJpxoomuKsPBEXRnkfrbUmm1z7RUS0jlk1FL 3hbRugsS7EGcxbbCpyqiJynAex9VuyICNyAjhm0hg5E75lIlz30eW3k6SMJH+AeC DNmc2Oo6Xx3gWYSAXIUOum+3Mo5gmV19GjOEFWDEsBQ1wIB0HpO2xFv9fLA7l8/F 99UoupJ6kCmAHUqFGicm8bcBXtGHJIUf2aXKeUIMbGmwvIm853ae9l0K+TSy8Wml CM+N47u4QhSzHbT0KiaV+h8YJOWfF01Jp1VrrLkSWQ1NH5ZpIGeQY+yFy3gLkf6y EAsgGWjrp0FT2jWgqqMMalsAZiQpRQszfHl7NAIEcjskndDrSHE= =/it9 -----END PGP SIGNATURE----- --=-=-=-- --===============2116939337== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============2116939337==--