Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1052785ybi; Fri, 14 Jun 2019 07:52:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqw8Co2bOhqlGgSh6aE5OUIU2fnOkGDX8nbCp6n8wc69WittT9cyLhZAmJ2m2l056ptNILGF X-Received: by 2002:a17:902:7891:: with SMTP id q17mr38095261pll.236.1560523935160; Fri, 14 Jun 2019 07:52:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560523935; cv=none; d=google.com; s=arc-20160816; b=Er9O+KeiWSFblRHbd+gh8rbqP7iTmpLMN2027LtJzVNmuc4KjuNcK7/PhMGPPQQRTh ZqZ7T2VjMR5PzA9TuGw7lNeu3yEKMMoyZtkkZgtcuiPQzAlb24HmmK6gz+QgBSOqcRzQ e2Q7dYnW9GgL8WsLDubtFsPlGZvNsu/aAN1UYfyTWiPYYm6zjCMXDoe42wql4CHeEDVV fgeqKHYmgeDm5GqCnjiWKvn7gxkw+cuypwWxc92NaZYcCv30YfUSnb5fA5ZagaB+8HUf fxXMz0bGY569WO4ZR0i99oxBTkXpBgqqIVqyqN4tGR/8wE/cmXXxDkPzT4il1CcyZSnI Qhkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=PUURfEGuFA5Z9cKBc2KxhcoLizW6MsLNKxe6yaDcTfw=; b=lUoI38AL3jtLbfDXr5GAKhG0uHwU2Zv1N+svakTU10PHmQEyInowwOy16+nvhxrrJr a8p4HW3XP4eQZUyOJSNqUMvKfexowEfwBdzGwOVisDsLYoI6zz+1YIKBVDejZFVRB3l7 WAxwUvJNeeu+9zk+8MwrFOOM5+vTCtj/syk/GBo2NqOV8l/S46wmMHurLpTgkCuW8m2g 8zPl980s+Ubf7i6uKrmhknyIe3bU96Y0wOTeNkG37U0Mrg5wG03SSHNRgz9HUPBCJMNL XI2jzvlB61+5Li6PnKLenxW7gkE0IOHUeSqkuMrhJl3h2NETgP+JIN6v+omEgNw7ptNu Nlaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u65si2743609pgu.415.2019.06.14.07.51.59; Fri, 14 Jun 2019 07:52:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728797AbfFNOv6 (ORCPT + 99 others); Fri, 14 Jun 2019 10:51:58 -0400 Received: from mslow2.mail.gandi.net ([217.70.178.242]:56602 "EHLO mslow2.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727560AbfFNOv6 (ORCPT ); Fri, 14 Jun 2019 10:51:58 -0400 Received: from relay4-d.mail.gandi.net (unknown [217.70.183.196]) by mslow2.mail.gandi.net (Postfix) with ESMTP id 38F383AEE3F; Fri, 14 Jun 2019 14:24:17 +0000 (UTC) X-Originating-IP: 90.88.23.150 Received: from localhost (aaubervilliers-681-1-81-150.w90-88.abo.wanadoo.fr [90.88.23.150]) (Authenticated sender: maxime.ripard@bootlin.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 61125E0019; Fri, 14 Jun 2019 14:24:06 +0000 (UTC) Date: Fri, 14 Jun 2019 16:24:06 +0200 From: Maxime Ripard To: Jagan Teki Cc: David Airlie , Daniel Vetter , Chen-Yu Tsai , Michael Turquette , Rob Herring , Mark Rutland , linux-arm-kernel , linux-kernel , linux-clk , dri-devel , devicetree , Michael Trimarchi , linux-amarula , linux-sunxi Subject: Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI Message-ID: <20190614142406.ybdiqfppo5mc5bgq@flea> References: <20190124195900.22620-1-jagan@amarulasolutions.com> <20190124195900.22620-12-jagan@amarulasolutions.com> <20190125212433.ni2jg3wvpyjazlxf@flea> <20190129151348.mh27btttsqcmeban@flea> <20190201143102.rcvrxstc365mezvx@flea> <20190605064933.6bmskkxzzgn35xz7@flea> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="npvcnqi5yg4bofaa" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --npvcnqi5yg4bofaa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard wrote: > > > > Hi, > > > > I've reordered the mail a bit to work on chunks > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > 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 == > > > > 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 > > > > > > Let me explain, something more. > > > > > > According to bsp there are clk_info.tcon_div which I will explain below. > > > clk_info.dsi_div which is dynamic and it depends on bpp/lanes, so it > > > is 6 for 24bpp and 4 lanes devices. > > > > > > PLL rate here depends on dsi_div (not tcon_div) > > > > > > Code here > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L784 > > > > > > is computing the actual set rate, which depends on dsi_rate. > > > > > > lcd_rate = dclk_rate * clk_info.dsi_div; > > > dsi_rate = pll_rate / clk_info.dsi_div; > > > > > > Say if the dclk_rate 148MHz then the dsi_rate is 888MHz which set rate > > > for above link you mentioned. > > > > > > Here are the evidence with some prints. > > > > > > https://gist.github.com/openedev/9bae2d87d2fcc06b999fe48c998b7043 > > > https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a > > > > Ok, so we agree up to this point, and the prints confirm that the > > analysis above is the right one. > > > > > > 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 > > > > Your patch doesn't address that, so let's leave that one alone. > > Basically this is final pll set rate when sun4i_dotclock.c called the > desired rate with ccu_nkm.c so it ended the final rate with parent as > Line 8 of > https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a If that's important to the driver, it should be set explicitly then, and not work by accident. > > > > 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 > > > > > > tcon_div from BSP point-of-view of there are two variants > > > 00) clk_info.tcon_div which is 4 and same is set the divider position > > > in SUN4I_TCON0_DCLK_REG (like above link refer) > > > 01) tcon_div which is 4 and used for edge timings computation > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12 > > > > > > The real reason for 01) is again 4 is they set the divider to 4 in 00) > > > which is technically wrong because the dividers which used during > > > dotclock in above (dsi_div) should be used here as well. Since there > > > is no dynamic way of doing this BSP hard-coding these values. > > > > > > Patches 5,6,7 on this series doing this > > > https://patchwork.freedesktop.org/series/60847/ > > > > > > Hope this explanation helps? > > > > It doesn't. > > > > The clock tree is this one: > > > > PLL(s) -> TCON module clock -> TCON dotclock. > > > > The links I mentioned above show that the clock set to lcd_rate is the > > TCON module clocks (and it should be the one taking the bpp and lanes > > into account), while the TCON dotclock uses a fixed divider of 4. > > Sorry, I can argue much other-than giving some code snips, according to [1] > > 00) Line 785, 786 with dclk_rate 148000000 > > lcd_rate = dclk_rate * clk_info.dsi_div; > pll_rate = lcd_rate * clk_info.lcd_div; > > Since dsi_div is 6 (bpp/lanes), lcd_div 1 > > lcd_rate = 888000000, pll_rate = 888000000 > > 01) Line 801, 804 are final rates computed as per clock driver (say > ccu_nkm in mainline) > > lcd_rate_set=891000000 > > As per your comments if it would be 4 then the desired numbers are > would be 592000000 not 888000000. > > This is what I'm trying to say in all mails, and same as verified with > 2-lanes devices as well where the dsi_div is 12 so the final rate is > 290MHz * 12 In the code you sent, you're forcing a divider on the internal TCON clock, while that one is fixed in the BSP. There's indeed the bpp / lanes divider, but it's used in the *parent* clock of the one you're changing. And the dsi0_clk clock you pointed out in the code snippet is yet another clock, the MIPI DSI module clock. The analysis you have is probably correct, you're just not implementing it properly in your patch. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --npvcnqi5yg4bofaa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXQOuBgAKCRDj7w1vZxhR xVScAPwJAh0zbjS2D2GVNKLA/jet+pw0LYampil65HFHY37fKgEAj5hO1cJdHIPM IjOKl6B/qRBrtcW9BEpz5/abyaOyogE= =uMQI -----END PGP SIGNATURE----- --npvcnqi5yg4bofaa--