Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113AbdHDVQQ (ORCPT ); Fri, 4 Aug 2017 17:16:16 -0400 Received: from anholt.net ([50.246.234.109]:49604 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751323AbdHDVQP (ORCPT ); Fri, 4 Aug 2017 17:16:15 -0400 From: Eric Anholt To: Boris Brezillon Cc: dri-devel@lists.freedesktop.org, Archit Taneja , Andrzej Hajda , Laurent Pinchart , Thierry Reding , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/6] drm/vc4: Avoid using vrefresh==0 mode in DSI htotal math. In-Reply-To: <20170804105304.68e3b02a@bbrezillon> References: <20170718210510.12229-1-eric@anholt.net> <20170804105304.68e3b02a@bbrezillon> User-Agent: Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 04 Aug 2017 14:15:56 -0700 Message-ID: <87r2wrm3ub.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3022 Lines: 76 --=-=-= 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----- --=-=-=--