Received: by 2002:a05:7412:3b8b:b0:fc:a2b0:25d7 with SMTP id nd11csp2455562rdb; Mon, 12 Feb 2024 05:42:01 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCU606G/67rAbdDO5UzzS0JOC7vXrxKZuiw/GXcsnaNf7wul+poBnz9vcQ1j2qvPJwDtQAnoXNytU8gY1cNGWXHPEbU6+qsGuAptNiCc2A== X-Google-Smtp-Source: AGHT+IFh0QO0zoH05Nj2fVOrB6tLJ09sU4R0cFYxHqLF9gD3QoO+S8ZtqTNc9qmoaR8lDH9cU+Ya X-Received: by 2002:a17:90b:50c:b0:297:b60:4db0 with SMTP id r12-20020a17090b050c00b002970b604db0mr8391498pjz.3.1707745321083; Mon, 12 Feb 2024 05:42:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707745321; cv=pass; d=google.com; s=arc-20160816; b=IMtIRF+eD0R1reLy0p5hOpHgMgUXxBKoHEbnEwVeG9YAw1EtgPDG/IdPpk/KLMurBs wRheIRgUHCJ5xROC6BEDGGw7sj2DPqvY+4PgycX3HmxAOAoiZZrshno64CRN/FdGVOUK FY7gNOw3vr9QjisJGfUzlHMPhbDj2IMmxbRQoDhoVoFGF25Lo3lJmHXeIsFmi6yJrBMY CdXnqnP34nBdJGyi8wNrebhfOOd5UA1Y4gPX1/RFhfHjOROipbecWDXfAhib5KG4WRZF 3OqRu3DM1TS+tU4P1Y+FzHx0Jym+MoTDIwYtIkiEHvHLA+bT+xt3624AoGp6MmtsGR1x iPCg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :message-id:date:in-reply-to:subject:cc:to:from:references :dkim-signature; bh=6hQXyKsjxlQOVZTDodnZAiw/5mwBoEpdiKUN3Omtj/4=; fh=uN3CSvCIUqlW4+lVmQZNajJnfh0c5RAgEUpqml5Y5gk=; b=Dpq04vd1PrIHoJUNZ+KIGlXuQP4aoPDwyJcbL2LTxGrKPgb4bnaWzOukwbGW7zz2H1 fBBS/E+cf5RDZNdUmLUakV5oZFhcqX5RGmAuxYY5WqIO3FuE0Q7WXHBubvSLGzZ+a2bd Q8WT6iMCTmt93uJ7yW7gIDLhWlEHsL8+b+K7vbWeuDtD7r+3z5fVd8eZy09IDRGsSyOW qBqTTCm27vjE/WK/Cb/jY2XfDZ6BcsuLeVhVl6Aq2daAGcWdXw72zyz4e8Q6PyhnlkUN 6I6UJ8ghzNbbtqTERzdAFGxVxkCEHfLUnsBMwX14t61wgDxj3TEGQAeiTT7AbRPxPujY GXsg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=vw0PaWBD; arc=pass (i=1 spf=pass spfdomain=oltmanns.dev dkim=pass dkdomain=oltmanns.dev dmarc=pass fromdomain=oltmanns.dev); spf=pass (google.com: domain of linux-kernel+bounces-61694-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61694-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev X-Forwarded-Encrypted: i=2; AJvYcCV+PlfxXL5WLzWaX8M3mfU763Q9sjoq2RkthUIFjXvvwIvd72yQlyYhUXhqEclTPyGmMdLFQKivgbFvNMwEECQu3fdfbBUwX0jqM3kBqw== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id x4-20020a17090aca0400b00296fba17af7si293286pjt.160.2024.02.12.05.42.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 05:42:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-61694-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=vw0PaWBD; arc=pass (i=1 spf=pass spfdomain=oltmanns.dev dkim=pass dkdomain=oltmanns.dev dmarc=pass fromdomain=oltmanns.dev); spf=pass (google.com: domain of linux-kernel+bounces-61694-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61694-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 75644280FB0 for ; Mon, 12 Feb 2024 13:39:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B38E14D5BD; Mon, 12 Feb 2024 13:29:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oltmanns.dev header.i=@oltmanns.dev header.b="vw0PaWBD" Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB7473C063; Mon, 12 Feb 2024 13:29:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707744574; cv=none; b=jjpY6GU5msKho7tRDv4/a7vhDLKGJvjsuB65Zh90BnCSmXQ2S2SxPOuHNuDj04G7GghWy0c9FruY1f4xpGAjDjhTHh77xCT9UD+gc29H1DngFB97CvnDDy3Y/l1cjfV20P1sPxYfLT3UUPEdYpmbjFp2nk6aMb0bKJXzHdA7+Z8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707744574; c=relaxed/simple; bh=U2euNzWu3qoY7qsLi74++0YSoMrQP1238IGSIcTeH/M=; h=References:From:To:Cc:Subject:In-reply-to:Date:Message-ID: MIME-Version:Content-Type; b=CY8r02xrSL/dQla7HWMTT8g0N8A2r0C0C7rbPtuuZ+dZqbv5fQoDUeoGI1kinJ+XNKF7wFXOzoZoqcueNw14nkrwtS1iLhgYaNOkogtei6/yDXbC/8pjUsoTGp6YT1YF6rvdsYREjUP0vOYTmFXSMRDPZ0CXUzBHPEnv/Jwn9W4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oltmanns.dev; spf=pass smtp.mailfrom=oltmanns.dev; dkim=pass (2048-bit key) header.d=oltmanns.dev header.i=@oltmanns.dev header.b=vw0PaWBD; arc=none smtp.client-ip=80.241.56.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oltmanns.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oltmanns.dev Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4TYQKY3z40z9sbq; Mon, 12 Feb 2024 14:29:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1707744561; 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=6hQXyKsjxlQOVZTDodnZAiw/5mwBoEpdiKUN3Omtj/4=; b=vw0PaWBD/K1z9/h6KAOxQ33Wa+sXzXwyrc5m8vXDM0DDGmCre4J5jA4GBLZR7mbU47XTIw xmU4VNFK7vajv6HhNe0qeV/VYW0cU6ZN1A9ESzAdmrAYpNG+HsG2hJjuexkJHndxTiZ8dv mzAX4NgZ6Ii525xOHXFDG/DruyFc95+VHeP7H0dzGEwf9wouGAdcNWnWH0dGaQiYojmmdq fmObgubotgbVFOmnNChdzKiMWeCKQXiysg18nifA0/OUb4SJavwo6yv4uruXLn+nA6LQ86 k0yfiWnHsdTs68XseNapwFnFCIHwAQc1oBBpyQjNVV+/n7yWOqFwVvR1nOmbOQ== References: <20240205-pinephone-pll-fixes-v2-0-96a46a2d8c9b@oltmanns.dev> <20240205-pinephone-pll-fixes-v2-5-96a46a2d8c9b@oltmanns.dev> <87sf1zxb0s.fsf@oltmanns.dev> From: Frank Oltmanns To: Maxime Ripard Cc: Michael Turquette , Stephen Boyd , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Guido =?utf-8?Q?G=C3=BCnther?= , Purism Kernel Team , Ondrej Jirman , Neil Armstrong , Jessica Zhang , Sam Ravnborg , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 5/6] drm/panel: st7703: Drive XBD599 panel at higher clock rate In-reply-to: <87sf1zxb0s.fsf@oltmanns.dev> Date: Mon, 12 Feb 2024 14:29:14 +0100 Message-ID: <87o7clyfo5.fsf@oltmanns.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 2024-02-11 at 16:42:43 +0100, Frank Oltmanns wrote: > On 2024-02-08 at 20:05:08 +0100, Maxime Ripard wrote: >> [[PGP Signed Part:Undecided]] >> Hi Frank, >> >> On Mon, Feb 05, 2024 at 04:22:28PM +0100, Frank Oltmanns wrote: >>> This panel is used in the pinephone that runs on a Allwinner A64 SOC. >>> The SOC requires pll-mipi to run at more than 500 MHz. >>> >>> This is the relevant clock tree: >>> pll-mipi >>> tcon0 >>> tcon-data-clock >>> >>> tcon-data-clock has to run at 1/4 the DSI per-lane bit rate. The XBD599 >>> has 24 bpp and 4 lanes. Therefore, the resulting requested >>> tcon-data-clock rate is: >>> crtc_clock * 1000 * (24 / 4) / 4 >>> >>> tcon-data-clock runs at tcon0 / 4 (fixed divisor), so it requests a >>> parent rate of >>> 4 * (crtc_clock * 1000 * (24 / 4) / 4) >>> >>> Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate of pll-mipi. >>> >>> pll-mipi's constraint to run at 500MHz or higher forces us to have a >>> crtc_clock >= 83333 kHz if we want a 60 Hz vertical refresh rate. >>> >>> Change [hv]sync_(start|end) so that we reach a clock rate of 83502 kHz >>> so that it is high enough to align with pll-pipi limits. >>> >>> Signed-off-by: Frank Oltmanns >> >> That commit log is great, but it's kind of off-topic. It's a panel >> driver, it can be used on any MIPI-DSI controller, the only relevant >> information there should be the panel timings required in the datasheet. >> >> The PLL setup is something for the MIPI-DSI driver to adjust, not for >> the panel to care for. >> > > I absolutely agree. It even was the reason for my submission of a > sunxi-ng patch series last year that was accepted, to make pll-mipi more > flexible. :) > > The only remaining option I currently see for adjusting the sunxi-ng > driver to further accomodate the panel, is trying to use a higher > divisor than 4 for calculating tcon-data-clock from tcon0. I remember > reading a discussion about this, but as far as I remember that proposal > was rejected (by you, IIRC). > > While I appreciate other suggestion as well, I'll look into options for > using a different divisor than 4. I tried the following: --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -391,7 +391,7 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon, * dclk is required to run at 1/4 the DSI per-lane bit rate. */ tcon->dclk_min_div = SUN6I_DSI_TCON_DIV; - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV; + tcon->dclk_max_div = 127; clk_set_rate(tcon->dclk, mode->crtc_clock * 1000 * (bpp / lanes) / SUN6I_DSI_TCON_DIV); On the pinephone, this selects a divisor of 6 resulting in a 25% frame drop. I.e., unless I'm missing something using a divisor other than 4 is not an option. This also matches your report from 2019: "Well, it's also breaking another panel." [1] I can currently see the following options: a. Drive PLL-MIPI outside spec and panel within spec (current situation, but missing a small patch [2] that fixes the crtc_clock and nothing else) and live with the fact that some pinephones will run unreliably. b. Drive PLL-MIPI and panel within spec and shove data into the panel at a too high rate (i.e., apply the rest of this series but not this specific patch). This seems to mostly work, but hasn't seen any long term testing. Short term testing showed that this approach results in a slight but noticable unsmooth scrolling behavior. c. Drive PLL-MIPI within spec and panel outside spec (i.e., apply a future version of the whole series). This has been tested for over a month on three devices that I know of. There are no reports of panels not working with the suggested parameters. All options require additional work on the GPU rate which is currently being discussed in a parallel thread of this series. Unless somebody comes up with a better idea, I will pause working on fixing PLL-MIPI and focus on the GPU instead. While I doubt it, maybe fixing the GPU is sufficient and continuing to drive PLL-MIPI outside spec proves to be ok. [1]: https://lore.kernel.org/all/20190828130341.s5z76wejulwdgxlc@flea/ [2]: https://lore.kernel.org/all/20230219114553.288057-2-frank@oltmanns.dev/ Best regards, Frank > > Best regards, > Frank > >> >> Maxime >> >> [[End of PGP Signed Part]]