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 7C3AFC77B73 for ; Mon, 1 May 2023 13:42:59 +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:In-reply-to: Date: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=xheQilB7AturdAb8FKobfEUA4b75JNISdBSBLEGBRgw=; b=U1iIj9TgOuJriR CpInxIGIIdOKOcCFJ5oiQOTSnPxOPHuwGXwEi0q438Xoy6WbufuOwZhoi3TwrvFOumgT8gpJlhHGF TC1dt3SGS088OGGUK4CdfcJQzre3v2dkiIXKJSw78/AbUowWPDogVKcBWhvL5Gi82r8yk4yIHNbvg jbw4qUbh9U6bMgRTJFMXHciQvNPhe/QMaQzEYQrM1fwD6lQop8MLh+m7LWv2lEaAGBm5773K66qLf ZiIX3cWjJRUz3OSwoS/nrFqOvXkI8ZkcHxdhnVrZnuCDgoGSO5bAXODfkN5mPL2ZqsWan1SWZKxwk H7YcTunERjqPcVfK40dg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ptTn5-00G5N6-07; Mon, 01 May 2023 13:42:07 +0000 Received: from mout-p-101.mailbox.org ([80.241.56.151]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ptTn1-00G5MV-1s for linux-arm-kernel@lists.infradead.org; Mon, 01 May 2023 13:42:05 +0000 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Q94BX2xRGz9sVh; Mon, 1 May 2023 15:41:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1682948516; 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: in-reply-to:in-reply-to:references:references; bh=jqYP4L/dOQIMjnG4KNToVeLEt+0G6LtXeDVBdi/r+Rg=; b=zvcWH6KBDacptU5xkzi9uKyNMs3di7lqxMKl+ZHDf60qM2JjAQ9YphAvYDVbSp4Nk5p3/k BNusxtiVRWr91z42j93X8ZpJYR5717bDOnVJph+9WTy2BrlkdYDGy22ceS6sXfVnhzrH6z KDjDIkH59HlUqz0l4EtylDF5dJZda7BZhbKxBzcwzkf8sjq6ic08nLD+/7fYSRz6Efo4y6 ex2mdqmCTcVJH6vbiNj/NPkEf6hMLyz/VslpjDVkzIAoQNHd6F161qrCm4jkAXIa2bOC86 UFCOnfPeOhh2mQECnozaInvlast3VtVl1lwR1qngUtWw5XKKjtrTCbxqrYYffA== References: <20230418074008.69752-1-me@crly.cz> <87cz3uzpx1.fsf@oltmanns.dev> From: Frank Oltmanns To: Maxime Ripard , Jernej Skrabec Cc: Roman Beranek , Chen-Yu Tsai , David Airlie , Daniel Vetter , Samuel Holland , Ondrej Jirman , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/7] drm: sun4i: set proper TCON0 DCLK rate in DSI mode Date: Mon, 01 May 2023 15:40:49 +0200 In-reply-to: <87cz3uzpx1.fsf@oltmanns.dev> Message-ID: <87mt2o9njh.fsf@oltmanns.dev> MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Q94BX2xRGz9sVh X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230501_064203_843609_4A811086 X-CRM114-Status: GOOD ( 29.00 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Maxime, Jernej, I was trying to understand why pll-video0 is not updated and I tracked down the culprit to ccu_nkm.c. On 2023-04-23 at 15:24:33 +0200, Frank Oltmanns wrote: > On 2023-04-18 at 09:40:01 +0200, Roman Beranek wrote: >> According to Allwinner's BSP code, in DSI mode, TCON0 clock needs to be >> running at what's effectively the per-lane datarate of the DSI link. >> Given that the TCON DCLK divider is fixed to 4 (SUN6I_DSI_TCON_DIV), >> DCLK can't be set equal to the dotclock. Therefore labeling TCON DCLK >> as sun4i_dotclock or tcon-pixel-clock shall be avoided. >> >> With bpp bits per pixel transmitted over n DSI lanes, the target DCLK >> rate for a given pixel clock is obtained as follows: >> >> DCLK rate = 1/4 * bpp / n * pixel clock >> >> Effect of this change can be observed through the rate of Vblank IRQs >> which should now match refresh rate implied by set display mode. It >> was verified to do so on a A64 board with a 2-lane and a 4-lane panel. [...] > I've tried your patches on my pinephone. I also set the panel's clock to > 72 MHz, so at 24 bpp and 4 lanes that should result in a data clock of > 108 MHz. This should be possible when pll-video0 is at 297 MHz. > > Unfortunately, pll-video0 is not set and therefore the relevant part of > the clk_summary looks like this: > > enable prepare protect hardware > clock count count count rate enable > ------------------------------------------------------------------------ > pll-video0 1 1 1 294000000 Y > hdmi 0 0 0 294000000 N > tcon1 0 0 0 294000000 N > pll-mipi 1 1 1 431200000 Y > tcon0 2 2 1 431200000 Y > tcon-data-clock 1 1 1 107800000 Y > pll-video0-2x 0 0 0 588000000 Y > > Note, I've cut the columns accuracy, phase, and duty cycle, because they > show the same values for all clocks (0, 0, 50000). > > My understanding was that with this patchset setting the parent clock > should be possible. Do you have any idea why it doesn't work on the > pinephone? Or maybe it does work on yours and I'm making some kind of > mistake? To better understand what's going on I've extended the clk_rate_request class to also output the requested rate. The relevant output is this (leading line numbers by me for referencing the lines below): line 1: kworker/u8:2-49 [002] ..... 1.850141: clk_rate_request_start: tcon-data-clock rate 108000000 min 0 max 18446744073709551615, parent tcon0 (588000000) line 2: kworker/u8:2-49 [002] ..... 1.850149: clk_rate_request_start: tcon0 rate 432000000 min 0 max 18446744073709551615, parent pll-mipi (588000000) line 3: kworker/u8:2-49 [002] ..... 1.850154: clk_rate_request_start: pll-mipi rate 432000000 min 0 max 18446744073709551615, parent pll-video0 (294000000) line 4: kworker/u8:2-49 [002] ..... 1.850168: clk_rate_request_done: pll-mipi rate 431200000 min 0 max 18446744073709551615, parent pll-video0 (294000000) line 5: kworker/u8:2-49 [002] ..... 1.850169: clk_rate_request_done: tcon0 rate 431200000 min 0 max 18446744073709551615, parent pll-mipi (431200000) line 6: kworker/u8:2-49 [002] ..... 1.850171: clk_rate_request_done: tcon-data-clock rate 107800000 min 0 max 18446744073709551615, parent tcon0 (431200000) line 7: kworker/u8:2-49 [002] ..... 1.850172: clk_rate_request_start: tcon-data-clock rate 108000000 min 0 max 18446744073709551615, parent tcon0 (588000000) line 8: kworker/u8:2-49 [002] ..... 1.850174: clk_rate_request_start: tcon0 rate 432000000 min 0 max 18446744073709551615, parent pll-mipi (588000000) line 9: kworker/u8:2-49 [002] ..... 1.850179: clk_rate_request_start: pll-mipi rate 432000000 min 0 max 18446744073709551615, parent pll-video0 (294000000) line 10: kworker/u8:2-49 [002] ..... 1.850190: clk_rate_request_done: pll-mipi rate 431200000 min 0 max 18446744073709551615, parent pll-video0 (294000000) line 11: kworker/u8:2-49 [002] ..... 1.850191: clk_rate_request_done: tcon0 rate 431200000 min 0 max 18446744073709551615, parent pll-mipi (431200000) line 12: kworker/u8:2-49 [002] ..... 1.850192: clk_rate_request_done: tcon-data-clock rate 107800000 min 0 max 18446744073709551615, parent tcon0 (431200000) line 13: kworker/u8:2-49 [002] ..... 1.850193: clk_rate_request_start: tcon0 rate 431200000 min 0 max 18446744073709551615, parent pll-mipi (588000000) line 14: kworker/u8:2-49 [002] ..... 1.850195: clk_rate_request_start: pll-mipi rate 431200000 min 0 max 18446744073709551615, parent pll-video0 (294000000) line 15: kworker/u8:2-49 [002] ..... 1.850205: clk_rate_request_done: pll-mipi rate 431200000 min 0 max 18446744073709551615, parent pll-video0 (294000000) line 16: kworker/u8:2-49 [002] ..... 1.850206: clk_rate_request_done: tcon0 rate 431200000 min 0 max 18446744073709551615, parent pll-mipi (431200000) line 17: kworker/u8:2-49 [002] ..... 1.850208: clk_rate_request_start: pll-mipi rate 431200000 min 0 max 18446744073709551615, parent pll-video0 (294000000) line 18: kworker/u8:2-49 [002] ..... 1.850219: clk_rate_request_done: pll-mipi rate 431200000 min 0 max 18446744073709551615, parent pll-video0 (294000000) line 19: kworker/u8:2-49 [002] ..... 1.850229: clk_set_rate: pll-mipi 431200000 line 20: kworker/u8:2-49 [003] ..... 1.850508: clk_set_rate_complete: pll-mipi 431200000 line 21: kworker/u8:2-49 [003] ..... 1.850513: clk_set_rate: tcon0 431200000 line 22: kworker/u8:2-49 [003] ..... 1.850515: clk_set_rate_complete: tcon0 431200000 line 23: kworker/u8:2-49 [003] ..... 1.850516: clk_set_rate: tcon-data-clock 107800000 line 24: kworker/u8:2-49 [003] ..... 1.850524: clk_set_rate_complete: tcon-data-clock 107800000 line 25: kworker/u8:2-49 [003] ..... 1.853320: clk_prepare: tcon-data-clock line 26: kworker/u8:2-49 [003] ..... 1.853324: clk_prepare_complete: tcon-data-clock line 27: kworker/u8:2-49 [003] d..1. 1.853328: clk_enable: tcon-data-clock line 28: kworker/u8:2-49 [003] d..1. 1.853333: clk_enable_complete: tcon-data-clock In line 1 we can see that a rate of 108 MHz is requested for tcon-data-clock. In lines 2 and 3 this is forwarded to tcon0 and pll-mipi (432 MHz). What surprised me, is that there is no request to set the rate of pll-video0. Instead pll-mipi (and subsequently tcon0) are set to 431.2 MHz (lines 4,5) and consequently tcon-data-clock is at 107.8 MHz (line 6) as I also reported in my previous mail (see quote above). When figuring out the call stack, I traced the whole thing down to ccu_nkm_determine_rate(). The simplified call stack looks like this: clk_set_rate(tcon-data-clock, 108MHz) clk_core_set_rate_nolock(tcon-data-clock, 108MHz) clk_core_req_round_rate_nolock(tcon-data-clock, 108MHz) clk_core_round_rate_nolock(tcon-data-clock, 108MHz) sun4i_dclk_round_rate(tcon-data-clock) clk_hw_round_rate(tcon0, 432MHz) clk_core_round_rate_nolock(tcon0, 432MHz) clk_mux_determine_rate_flags(tcon0, 432MHz) clk_core_round_rate_nolock(pll-mipi, 432MHz) ccu_nkm_determine_rate(pll-mipi, 432MHz) Looking at ccu_nkm_determine_rate(), we've found our culprit because it does not try parent clock rates other than the current one. The same applies to all other ccu_nkm_* functions. So, I can see two options: a. Set pll-video0 to 297 MHz on boot b. Add functionality to ccu_nkm_* to also update the parent clock rate. I'm actually interested in tackling b, but I can't make any promises as to if and when I'll be able to solve it. I'm not certain about any side effects this might have. Until then, is option a acceptable in mainline? Thanks, Frank > > On a brighter note, when I initialize pll-video0 to 297 MHz in > sunxi-ng/ccu-sun50i-a64.c:sun50i_a64_ccu_probe() I get an even 108 Mhz > for the data clock. The patch is: > > writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG); > > + /* > + * Initialize PLL VIDEO0 to default values (297 MHz) > + * to clean up any changes made by bootloader > + */ > + writel(0x03006207, reg + 0x10); > + > ret = devm_sunxi_ccu_probe(&pdev->dev, reg, &sun50i_a64_ccu_desc); > if (ret) > return ret; > > Best, > Frank _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel