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 B05E9EB64D9 for ; Thu, 15 Jun 2023 14:47:53 +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:From:Message-ID:Subject:Cc:To: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=lux8Ou1hCYMjasRSo/OvnY5Jg5N8KBX8jUrUIFtZJcI=; b=ryYUTYpeGoLQoi8tHxOXxUO57d ZskQR+bicLDRz7Pn8YljhccKhWyPUduW2pszQPh+nCMGOmFk6o8pvrPNe/iPDup5qFlP/NXBZ+TUy duqOR+q2u8+Oivx0HCigINJCs4TJ90mnQ31BZcFM3Z4x9HXT40+YvmPrv19E9DmoSSEyO54Wf/aiJ pdwPfalN3YbXNesNSoq/pLrPg8raPre3h2s2XxPhSaILljNym5rDRefdBCGzrYd/GqIE87HJknTtT VdcoowMq57k6kRlEpIiKiUBisWJsxW2xMdQOjddRun2yU+wurlQpVviwVU9hpI3AKlyTUEyp05opd tIkIpOLg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q9oG1-00FCgF-2z; Thu, 15 Jun 2023 14:47:29 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q9oFz-00FCey-0G for linux-arm-kernel@lists.infradead.org; Thu, 15 Jun 2023 14:47:28 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DD6CD5C0110; Thu, 15 Jun 2023 10:47:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 15 Jun 2023 10:47:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1686840443; x=1686926843; bh=L5 CucTn2nK/6ilWkZCkYXAEXi37p54TLgVd4NqLySVs=; b=MrHyT4BAxtK6OrVF3/ NLgBLROkQsxwyC23Tz7wnZH7MfI0SqdzZDAoETPyuKL6DFN0JwUjfClpf2nTwe0h +HxlGW4hQm9fqEQrFCagN96GIqMaZdrolBgD+hgOxdNDYogWLbvp6IxKFOP1SCvy PRP8CwgQVsnGmz8g3PfZ0oOtsy9tt9nAnrhg05ffaY9f34qUjzoqv8V9vzxtEdm+ 9blvB6bf28rf2iLsqbwXlTm4ROZPas5SNVCowjaNd+4rL30VwwUsXGnY2GPF455A AxMMs3qBo+RXe8VliJ00RbjCr7jaK128GdbrG8W0gHScK07Y8fxWBDEgh1nVCB4s V4Hg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1686840443; x=1686926843; bh=L5CucTn2nK/6i lWkZCkYXAEXi37p54TLgVd4NqLySVs=; b=krLNryTD7nnL8EQElM93RdreP4Km6 SF8iXucPHaZGs6uaPqsYFHXvj/nvkNsmEri4NyGQP+Y3SeRFEDJKOzEyiflsnhcY 1Uuho+PrWrRvhoDcqD9JptrWxDd6WRkjjfSaLrb43Ze8NvX5nvtDB6mGXJMaJbl/ JkKcduFxuOf/GuI2L/Z1roABSJXZ814ouZzjD792yvO73jw/qc+5L+Pn01QSQccU m1eBk9YWeRuS/VS+gP6ssGa4hiemh2ScG+qVfMdddEpLV6TqOQkggDS4iMPcOYj/ RNQ9XfGgDrf1tJHZzmbQQOlN8nJXY0pDIMd/9Xq7jqcmHCbW5yITmJRZw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedvvddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffvvefukffhfhggtggujgesghdtsfertddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpefhhfehtdektdejueeltefhjeeltdffffejheffudfhvdfhhfeludekkefg hffhfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 15 Jun 2023 10:47:22 -0400 (EDT) Date: Tue, 13 Jun 2023 17:30:06 +0200 To: Frank Oltmanns Cc: Andre Przywara , Chen-Yu Tsai , Jernej Skrabec , Michael Turquette , Roman Beranek , Samuel Holland , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev Subject: Re: [PATCH 1/2] clk: sunxi-ng: nkm: consider alternative parent rates when finding rate Message-ID: From: Maxime Ripard References: <20230605190745.366882-1-frank@oltmanns.dev> <20230605190745.366882-2-frank@oltmanns.dev> <2bvcukogzhcdbfsrruylgw5fbezaqjpcojqaambfoiv5fc2upy@ffumn5sevbeb> <875y7y1f0d.fsf@oltmanns.dev> <87a5x41w5r.fsf@oltmanns.dev> <87wn07zmxp.fsf@oltmanns.dev> MIME-Version: 1.0 In-Reply-To: <87wn07zmxp.fsf@oltmanns.dev> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230615_074727_345163_CF061286 X-CRM114-Status: GOOD ( 28.25 ) 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="===============3882852898932302498==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3882852898932302498== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cghg4gjbgxgwxw55" Content-Disposition: inline --cghg4gjbgxgwxw55 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 13, 2023 at 12:17:06PM +0200, Frank Oltmanns wrote: > Hi Maxime, >=20 > I'll now only respond to one aspect of your mail, because it's the > foundation for the whole behaviour. >=20 > On 2023-06-13 at 11:10:08 +0200, Maxime Ripard wrote: > [...] > >> >> ccu_nkm_find_best is called in the following two situations: > >> >> a. from ccu_nkm_set_rate when setting the rate > >> >> b. from ccu_nkm_round_rate when determining the rate > >> >> > >> >> In situation a. we never want ccu_nkm_find_best to try different pa= rent > >> >> rates because setting the parent rate is a done deal (at least that= 's my > >> >> understanding). > >> >> > >> >> In situation b. we only want ccu_nkm_find_best to try different par= ent > >> >> rates when, as you mentioned, the CLK_SET_RATE_PARENT flag is set. > >> > > >> > It doesn't really matter though. The output of that function must be > >> > stable and must return the same set of factors and parent rate for a > >> > given target rate. > >> > > >> > >> I'm not sure if we're talking about the same thing here. Of course the > >> set of factors and parent rate for a given target rate will be differe= nt > >> depending on the fact if we can or cannot adjust the parent rate, > >> agreed? > > > > Yes, but here you also have a different behaviour in clk_round_rate() > > and in clk_set_rate(), which isn't ok. > > > > Basically, clk_set_rate() + clk_get_rate() must be equal to > > clk_round_rate(). > > > > If you change if you look for parents depending on whether you're being > > called in clk_round_rate() and clk_set_rate(), then you're breaking that > > expectation. > > > >> Let me compare my implementation to ccu_mp. > >> > >> ccu_mp_round_rate either calls the function ccu_mp_find_best or > >> ccu_mp_find_best_with_parent_adj, depending on CLK_SET_RATE_PARENT. > > > > Yes, and it's fine: the flag is per-clock, and the output is the same > > depending on whether we're being called by clk_round_rate() and > > clk_set_rate(). > > >=20 > The output is really not the same. >=20 > ccu_mp_set_rate() always calls ccu_mp_find_best(). It never (!) considers > changing the parent, independent of any flags. >=20 > ccu_mp_round_rate() is calling ccu_mp_find_best() OR > ccu_mp_find_best_with_parent_adj() depending on the flag. >=20 > If I understand you correctly, you consider that a bug. No, sorry, you're right. clk_set_rate will call round_rate first, which will (possibly) pick up a new parent, and by the time set_rate is called our parent will have been changed already so we will just call find_best again considering only that parent. The set of factors and dividers should remain the same there, but I don't think that's a concern. That leaves us with the rounding stuff, and the overall function arguments. I like the structure of ccu_mp better, is there a reason to deviate from it? Maxime --cghg4gjbgxgwxw55 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZIiLeQAKCRDj7w1vZxhR xZwOAP0V27baWBPmfpGaKZQrnd/GOqaGcGGZZuCPI3ZDiH4lzAD/RqTkEXmNCeP+ vkcuc67x9IsePwvMFq3jBor1njpnVgc= =84G2 -----END PGP SIGNATURE----- --cghg4gjbgxgwxw55-- --===============3882852898932302498== 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 --===============3882852898932302498==--