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 6F832C54E60 for ; Thu, 14 Mar 2024 14:42:45 +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-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc: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=zX1ptjuoIXeXTv2Wu3RWY6XVumQVHBYWVVxUnFsneFE=; b=BJyRxClix9bQGt4Y3OOKIYf1Kr VugD35iaoSx0RXAvHk76Bt3WvOlrfd1dDntBpDC978zhHx0XxJCaAjzYYi4cYIvIAoRhTXV1+uaEj RDeCbba68yY9fNwW99/yr352Y+osZxefSNUZRjsMwV682vnzeaqWdMZUCbzKBAT97a3xnV23Vqtnp wNpcRsSvc1t9m7HcHDtdEoD8aadLcj6k/fPkRppBfb7v0Ty5r4hO8Hghblt7g4dZ2oCT3pCrizR1Q APHA3LseZGZPAvDSS5xOsONYP2HMHDeUcrVtHmQswBh6YkZkMw0NtF7OHYpK7MN1FouAFuLThM598 LkvujeTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rkmHx-0000000Egv4-12Od; Thu, 14 Mar 2024 14:42:33 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rkmHs-0000000EgtD-20qa for linux-arm-kernel@lists.infradead.org; Thu, 14 Mar 2024 14:42:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7F381614E6; Thu, 14 Mar 2024 14:42:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA74DC433C7; Thu, 14 Mar 2024 14:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1710427347; bh=t15/fUG8eEoCH9k/jfp6Z2u74HuUtlgqyLfEcx09Zp4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I/F+lDGS2y5xE5a5YA7GzDQLaThIZmXKLcUXFYPQFaGsCyeslKqQd7z1bZgb+ttps p5mDSY9dX7k5N4dsQUhv1iOtQsRWuHo8AEQwqNHtJvj8iWE+28xfJ6cLUgkfpw5Dy6 FbdjrkPuMlr12cVAvOmggmYlSPsWGdjjeyY6KKSz6ONecqBDXb7gNac7Wp4FoC3dLc 6ZNoHDmv98FB+bCPD3Uy/z4vuqh9rh69Qy3RDzDbAMxENPSBF4hFT2fC09ubBRpWbv ZDZoRRNkfMhzvDAdhzqCrY2AYJmjVfor08S+wsnhihdijuUoj0jTst4SswmtBSPxBn G4RFR8dxu6BwA== Date: Thu, 14 Mar 2024 15:42:24 +0100 From: Maxime Ripard To: Frank Oltmanns Cc: Chen-Yu Tsai , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , Jernej Skrabec , Samuel Holland , Icenowy Zheng , 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] drm/sun4i: tcon: Support keeping dclk rate upon ancestor clock changes Message-ID: <20240314-careful-silky-bear-8ee43f@houat> References: <20240310-tcon_keep_stable_rate-v1-1-0296b0a85c02@oltmanns.dev> MIME-Version: 1.0 In-Reply-To: <20240310-tcon_keep_stable_rate-v1-1-0296b0a85c02@oltmanns.dev> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240314_074228_638479_70CD2BE0 X-CRM114-Status: GOOD ( 23.73 ) 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: multipart/mixed; boundary="===============4900607043676654897==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============4900607043676654897== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nskffof7joxt6vlb" Content-Disposition: inline --nskffof7joxt6vlb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Mar 10, 2024 at 02:32:29PM +0100, Frank Oltmanns wrote: > Allow the dclk to reset its rate when a rate change is initiated from an > ancestor clock. This makes it possible to no longer to get an exclusive > lock. As a consequence, it is now possible to set new rates if > necessary, e.g. when an external display is connected. >=20 > The first user of this functionality is the A64 because PLL-VIDEO0 is an > ancestor for both HDMI and TCON0. This allows to select an optimal rate > for TCON0 as long as there is no external HDMI connection. Once a change > in PLL-VIDEO0 is performed when an HDMI connection is established, TCON0 > can react gracefully and select an optimal rate based on this the new > constraint. >=20 > Signed-off-by: Frank Oltmanns > --- > I would like to make the Allwinner A64's data-clock keep its rate > when its ancestor's (pll-video0) rate changes. Keeping data-clock's rate > is required, to let the A64 drive both an LCD and HDMI display at the > same time, because both have pll-video0 as an ancestor. >=20 > TCONs that use this flag store the ideal rate for their data-clock and > subscribe to be notified when data-clock changes. When rate setting has > finished (indicated by a POST_RATE_CHANGE event) the call back function > schedules delayed work to set the data-clock's rate to the initial value > after 100 ms. Using delayed work maks sure that the clock setting is > finished. >=20 > I've implemented this functionality as a quirk, so that it is possible > to use it only for the A64. >=20 > This patch supersedes [1]. >=20 > This work is inspired by an out-of-tree patchset [2] [3] [4]. > Unfortunately, the patchset uses clk_set_rate() directly in a notifier > callback, which the following comment on clk_notifier_register() > forbids: "The callbacks associated with the notifier must not re-enter > into the clk framework by calling any top-level clk APIs." [5] > Furthermore, that out-of-tree patchset no longer works since 6.6, > because setting pll-mipi is now also resetting pll-video0 and therefore > causes a race condition. Workqueues don't have an upper boundary on when they execute. As we discussed multiple times, this should be solved in the clock framework itself, not bypassing it. Maxime --nskffof7joxt6vlb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZfMMzwAKCRDj7w1vZxhR xQ1CAQDtICAPI7t6iHcGTsvHtbMc/Xou8mIobymUHWIa2ywO5QEAyvQlO/lPQtZc I6gmabMvtrOKzIunluaotAq5NsaVYQY= =IRk2 -----END PGP SIGNATURE----- --nskffof7joxt6vlb-- --===============4900607043676654897== 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 --===============4900607043676654897==--