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 X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8C79C282D8 for ; Fri, 1 Feb 2019 14:31:23 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 7BEF9218AC for ; Fri, 1 Feb 2019 14:31:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FQlZoDr9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7BEF9218AC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jR9MGfayxmRJREx7T8+uPjaX94FM68sXFdAGbbjLghQ=; b=FQlZoDr9fmTsEdlS4C5P191hB 7t23JGPC+t+tszAuJpBkw58fcwGVhfHvkN6w7xz5PWBf9U5iwQDAlWDrWJe5raFAXFwsrezC/5/oH Ys88DWOkNQOpei6LFJrWjMCYtXMfZs5xMpk2fV+gfq9Fbb16FGLvg2rD7NGmlKYm2RgN5Am48QZYb qcsHAYJsHOSnwnvJq0GuTMAF28E8nddoTAKYK6V8af7X4Gh8zuv0takiGEvblOTDaPvVs++G+j8kv NUDgfHLw0NAN34vkunCX5d78dXTIusn2+2Kd3KFN54KdUMyjISFjuYddTOQt6yAgbS25/GFZ7V6b9 W6fgEnVcQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gpZqe-0001df-Md; Fri, 01 Feb 2019 14:31:16 +0000 Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gpZqa-0001Zq-26 for linux-arm-kernel@lists.infradead.org; Fri, 01 Feb 2019 14:31:14 +0000 X-Originating-IP: 90.88.147.226 Received: from localhost (aaubervilliers-681-1-27-226.w90-88.abo.wanadoo.fr [90.88.147.226]) (Authenticated sender: maxime.ripard@bootlin.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id EAC1F1C0016; Fri, 1 Feb 2019 14:31:02 +0000 (UTC) Date: Fri, 1 Feb 2019 15:31:02 +0100 From: Maxime Ripard To: Jagan Teki Subject: Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI Message-ID: <20190201143102.rcvrxstc365mezvx@flea> References: <20190124195900.22620-1-jagan@amarulasolutions.com> <20190124195900.22620-12-jagan@amarulasolutions.com> <20190125212433.ni2jg3wvpyjazlxf@flea> <20190129151348.mh27btttsqcmeban@flea> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190201_063112_433963_C19A0EBB X-CRM114-Status: GOOD ( 31.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree , David Airlie , Michael Turquette , linux-sunxi , linux-kernel , dri-devel , Chen-Yu Tsai , Rob Herring , Daniel Vetter , Michael Trimarchi , linux-amarula@amarulasolutions.com, linux-clk , linux-arm-kernel Content-Type: multipart/mixed; boundary="===============7634344483858412553==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7634344483858412553== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="urqj3qodl5kincq4" Content-Disposition: inline --urqj3qodl5kincq4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote: > On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard = wrote: > > > > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote: > > > On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard wrote: > > > > > > > > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote: > > > > > Minimum PLL used for MIPI is 500MHz, as per manual, but > > > > > lowering the min rate by 300MHz can result proper working > > > > > nkms divider with the help of desired dclock rate from > > > > > panel driver. > > > > > > > > > > Signed-off-by: Jagan Teki > > > > > Acked-by: Stephen Boyd > > > > > > > > Going 200MHz below the minimum doesn't seem really reasonable. What > > > > is the issue that you are trying to fix here? > > > > > > > > It looks like it's picking bad dividers, but if that's the case, th= is > > > > isn't the proper fix. > > > > > > As I stated in earlier patches, the whole idea is pick the desired > > > dclk divider based dclk rate. So the dotclock, sun4i_dclk_round_rate > > > is unable to get the proper dclk divider at the end, so it eventually > > > picking up wrong divider value and fired vblank timeout. > > > > > > So, we come-up with optimal and working min_rate 300MHz in pll-mipi to > > > get the desired clock something like below. > > > [ 2.415773] [drm] No driver support for vblank timestamp query. > > > [ 2.424116] sun4i_dclk_round_rate: min_div =3D 4 max_div =3D 127, = rate =3D 55000000 > > > [ 2.424172] ideal =3D 220000000, rounded =3D 0 > > > [ 2.424176] ideal =3D 275000000, rounded =3D 0 > > > [ 2.424194] ccu_nkm_round_rate: rate =3D 330000000 > > > [ 2.424197] ideal =3D 330000000, rounded =3D 330000000 > > > [ 2.424201] sun4i_dclk_round_rate: div =3D 6 rate =3D 55000000 > > > [ 2.424205] sun4i_dclk_round_rate: min_div =3D 4 max_div =3D 127, = rate =3D 55000000 > > > [ 2.424209] ideal =3D 220000000, rounded =3D 0 > > > [ 2.424213] ideal =3D 275000000, rounded =3D 0 > > > [ 2.424230] ccu_nkm_round_rate: rate =3D 330000000 > > > [ 2.424233] ideal =3D 330000000, rounded =3D 330000000 > > > [ 2.424236] sun4i_dclk_round_rate: div =3D 6 rate =3D 55000000 > > > [ 2.424253] ccu_nkm_round_rate: rate =3D 330000000 > > > [ 2.424270] ccu_nkm_round_rate: rate =3D 330000000 > > > [ 2.424278] sun4i_dclk_recalc_rate: val =3D 1, rate =3D 330000000 > > > [ 2.424281] sun4i_dclk_recalc_rate: val =3D 1, rate =3D 330000000 > > > [ 2.424306] ccu_nkm_set_rate: rate =3D 330000000, parent_rate =3D = 297000000 > > > [ 2.424309] ccu_nkm_set_rate: _nkm.n =3D 5 > > > [ 2.424311] ccu_nkm_set_rate: _nkm.k =3D 2 > > > [ 2.424313] ccu_nkm_set_rate: _nkm.m =3D 9 > > > [ 2.424661] sun4i_dclk_set_rate div 6 > > > [ 2.424668] sun4i_dclk_recalc_rate: val =3D 6, rate =3D 55000000 > > > > > > But look like this wouldn't valid for all other dclock rates, say BPI > > > panel has 30MHz clock that would failed with this logic. > > > > > > On the other side Allwinner BSP calculating dclk divider based on the > > > SoC's. for A33 [1] it is fixed dclk divider of 4 and for A64 is is > > > calculated based on the bpp/lanes. > > > > It looks like the A64 has the same divider of 4: > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/dri= vers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12 > > > > I think you're confusing it with the ratio between the pixel clock and > > the dotclock, called dsi_div: > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/dri= vers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L198 >=20 > Ahh.. I thought this initially but as far as DSI clock computation is > concern, the L12 tcon_div is local variable which is used for edge0 > computation in burst mode and not for the dsi clock computation. Since > the BSP is unable to get the tcon_div during edge0 computation, they > defined it locally I think. >=20 > You can see the lcd_clk_config() code [2], where we can see DSI clock > computation using dsi_div value. >=20 > Here is dump after the in Line 792 which is after computation[3] > [ 10.800737] lcd_clk_config: dsi_div =3D 6, tcon_div =3D 4, lcd_div =3D= 1 > [ 10.800743] lcd_clk_config: lcd_dclk_freq =3D 55, dclk_rate =3D 550000= 00 > [ 10.800749] lcd_clk_config: lcd_rate =3D 330000000, pll_rate =3D 33000= 0000 >=20 > The above dump the lcd_rate 330MHz is computed with panel clock, 55MHz > into dsi_div 6. So this can be our actual divider values dclk_min_div, > dclk_max_div in sun4i_dclk_round_rate (from > drivers/gpu/drm/sun4i/sun4i_dotclock.c) I wish it was in your commit log in the first place, instead of having to exchange multiple mails over this. However, I don't think that's quite true, and it might be a bug in Allwinner's implementation (or rather something quite confusing). You're right that the lcd_rate and pll_rate seem to be generated from the pixel clock, and it indeed looks like the ratio between the pixel clock and the TCON dotclock is defined through the number of bits per lanes. However, in this case, dsi_rate is actually the same than lcd_rate, since pll_rate is going to be divided by dsi_div: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers= /video/sunxi/disp2/disp/de/disp_lcd.c#L791 Since lcd_div is 1, it also means that in this case, dsi_rate =3D=3D dclk_rate. The DSI module clock however, is always set to 148.5 MHz. Indeed, if we look at: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers= /video/sunxi/disp2/disp/de/disp_lcd.c#L804 We can see that the rate in clk_info is used if it's different than 0. This is filled by disp_al_lcd_get_clk_info, which, in the case of a DSI panel, will hardcode it to 148.5 MHz: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers= /video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L164 So, the DSI clock is set to this here: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers= /video/sunxi/disp2/disp/de/disp_lcd.c#L805 The TCON *module* clock (the one in the clock controller) has been set to lcd_rate (so the pixel clock times the number of bits per lane) here: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers= /video/sunxi/disp2/disp/de/disp_lcd.c#L800 And the PLL has been set to the same rate here: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers= /video/sunxi/disp2/disp/de/disp_lcd.c#L794 Let's take a step back now: that function we were looking at, lcd_clk_config, is called by lcd_clk_enable, which is in turn called by disp_lcd_enable here: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers= /video/sunxi/disp2/disp/de/disp_lcd.c#L1328 The next function being called is disp_al_lcd_cfg, and that function will hardcode the TCON dotclock divider to 4, here: https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers= /video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L240 So, in the end, the dotclock divider is always 4, the DSI module clock is set to 148.5 MHz, and the TCON module clock is set to 330MHz. Since the TCON module clock doesn't have a divider, the PLL is set at that same value but this is redundant. I'll experiment with this and try to see how it works on the A33. Maxime --=20 Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --urqj3qodl5kincq4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXFRYJgAKCRDj7w1vZxhR xfk1AP0YYiPz6HNP9ogNtQ6Jh569R/4FrmJVRvNinOU996BHZwD5Ac7BWF6vemm8 X7hfMI/eE+VKFy6nuN638kCJO510Yg0= =5uP8 -----END PGP SIGNATURE----- --urqj3qodl5kincq4-- --===============7634344483858412553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7634344483858412553==--