From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4ABEC8490 for ; Fri, 4 Nov 2022 18:11:26 +0000 (UTC) Received: by mail-wm1-f43.google.com with SMTP id v7so3493753wmn.0 for ; Fri, 04 Nov 2022 11:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:from:to:cc:subject:date:message-id :reply-to; bh=CgAHyV5MssUU8DmgqTLqByPHjrUlZTpRzsXy7QZTV1w=; b=m1k1aGhFcGwAzy8+jR8i8dgnxBKgmbv+HEcBN9clOnBC8JDxQ1WLH/jaC98+SUuhn1 ojpUIvzLvAjOEtONQNG3fEjMYr6YmyE21HCNBu13dHQQCKT1MZYzip/HLcRMuJacgFsk D55A4srqhE9k1graGmYJvC73InZQsK8+3y7hORWhx8V9sPZvLSdaAKZue8yFET0sqAK6 QCfmTlWLBXdiCGceVK43T3rcfW1aWRAA7EsaVybuem8YgF0fY+TkmF3j/WgfSTXHeBZr 9yfwVW6BUgHERrFBi1RgnqxfwanJH3Intmfl0rdZ0bNVoL/stqFGyIUMqw38czj+U/IY +ZRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=CgAHyV5MssUU8DmgqTLqByPHjrUlZTpRzsXy7QZTV1w=; b=DR9q8plhzZJpBNUVl1pZG+4aHqoy0CJ9LSBZul40RlirLXtO3syCrmAlQ+XXSmZeg0 md42azOmpLycyFLRxXWqwK9fRFH46D4jiGxIR0RUpcAkj1qvG+ANMDCWoBwFTibFX8eE JWHq5IMCW+e82uALGmeuT0QFjQCJU0rd3J5oWVqZro4iYRcqnzJeL+sYDAj5qmZ+lPp5 icSglojN+/3wzOXUq+zCBg23bOrWw50dlkJZmpDbFAyH91hAdk9bwMokXs/z3W5dQSZE rjTVG1gadFnxfyhgoA48CazuSOJfzL8ucs3MvqORh5bdoGjcQYBZP78uBkv3KJTXD5mj 5CUg== X-Gm-Message-State: ACrzQf2ukkf/H0nMENShEud2wb6bP1MBOtgN04n0frIJ6VrEJprko/GC FgzHpnRAyZqnK/OYG3shEDo= X-Google-Smtp-Source: AMsMyM5+00Cvx4Zit5cSiVEHfTNn4dr0i6mIADmjwE6QFA7y0/yyBqq7C4ech+m2YPARidv5n/8G+w== X-Received: by 2002:a05:600c:21c9:b0:3cf:68f8:7901 with SMTP id x9-20020a05600c21c900b003cf68f87901mr283147wmj.69.1667585484372; Fri, 04 Nov 2022 11:11:24 -0700 (PDT) Received: from localhost (94.197.10.32.threembb.co.uk. [94.197.10.32]) by smtp.gmail.com with ESMTPSA id az2-20020adfe182000000b00226dba960b4sm36409wrb.3.2022.11.04.11.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 11:11:23 -0700 (PDT) References: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> <20221018-clk-range-checks-fixes-v2-56-f6736dec138e@cerno.tech> <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> From: Aidan MacDonald To: Maxime Ripard Cc: Paul Cercueil , Stephen Boyd , Maxime Coquelin , Chen-Yu Tsai , Daniel Vetter , Nicolas Ferre , Thierry Reding , Jaroslav Kysela , Shawn Guo , Fabio Estevam , Ulf Hansson , Claudiu Beznea , Michael Turquette , Dinh Nguyen , Chunyan Zhang , Manivannan Sadhasivam , Andreas =?utf-8?Q?F=C3=A4rber?= , Jonathan Hunter , Abel Vesa , Charles Keepax , Alessandro Zummo , Peter De Schrijver , Orson Zhai , Alexandre Torgue , Prashant Gaikwad , Liam Girdwood , Alexandre Belloni , Samuel Holland , Matthias Brugger , Richard Fitzgerald , Vinod Koul , NXP Linux Team , Sekhar Nori , Kishon Vijay Abraham I , Linus Walleij , Takashi Iwai , David Airlie , Luca Ceresoli , Jernej Skrabec , Pengutronix Kernel Team , Baolin Wang , David Lechner , Sascha Hauer , Mark Brown , Max Filippov , Geert Uytterhoeven , linux-stm32@st-md-mailman.stormreply.com, alsa-devel@alsa-project.org, linux-mediatek@lists.infradead.org, linux-phy@lists.infradead.org, linux-mips@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-actions@lists.infradead.org, linux-clk@vger.kernel.org, AngeloGioacchino Del Regno , patches@opensource.cirrus.com, linux-tegra@vger.kernel.org, linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate Date: Fri, 04 Nov 2022 17:35:29 +0000 In-reply-to: <20221104145946.orsyrhiqvypisl5j@houat> Message-ID: Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maxime Ripard writes: > Hi Paul, > > On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote: >> Le ven. 4 nov. 2022 =C3=A0 14:18:13 +0100, Maxime Ripard a >> =C3=A9crit : >> > The Ingenic CGU clocks implements a mux with a set_parent hook, but >> > doesn't provide a determine_rate implementation. >> > >> > This is a bit odd, since set_parent() is there to, as its name implies, >> > change the parent of a clock. However, the most likely candidate to >> > trigger that parent change is a call to clk_set_rate(), with >> > determine_rate() figuring out which parent is the best suited for a >> > given rate. >> > >> > The other trigger would be a call to clk_set_parent(), but it's far le= ss >> > used, and it doesn't look like there's any obvious user for that clock. >> > >> > So, the set_parent hook is effectively unused, possibly because of an >> > oversight. However, it could also be an explicit decision by the >> > original author to avoid any reparenting but through an explicit call = to >> > clk_set_parent(). >> > >> > The driver does implement round_rate() though, which means that we can >> > change the rate of the clock, but we will never get to change the >> > parent. >> > >> > However, It's hard to tell whether it's been done on purpose or not. >> > >> > Since we'll start mandating a determine_rate() implementation, let's >> > convert the round_rate() implementation to a determine_rate(), which >> > will also make the current behavior explicit. And if it was an >> > oversight, the clock behaviour can be adjusted later on. >> >> So it's partly on purpose, partly because I didn't know about >> .determine_rate. >> >> There's nothing odd about having a lonely .set_parent callback; in my ca= se >> the clocks are parented from the device tree. >> >> Having the clocks driver trigger a parent change when requesting a rate >> change sounds very dangerous, IMHO. My MMC controller can be parented to= the >> external 48 MHz oscillator, and if the card requests 50 MHz, it could sw= itch >> to one of the PLLs. That works as long as the PLLs don't change rate, bu= t if >> one is configured as driving the CPU clock, it becomes messy. >> The thing is, the clocks driver has no way to know whether or not it is >> "safe" to use a designated parent. >> >> For that reason, in practice, I never actually want to have a clock >> re-parented - it's almost always a bad idea vs. sticking to the parent c= lock >> configured in the DTS. > > Yeah, and this is totally fine. But we need to be explicit about it. The > determine_rate implementation I did in all the patches is an exact > equivalent to the round_rate one if there was one. We will never ask to > change the parent. > > Given what you just said, I would suggest to set the > CLK_SET_RATE_NO_REPARENT flag as well. > Ideally there should be a way for drivers and the device tree to say, "clock X must be driven by clock Y", but the clock framework would be allowed to re-parent clocks freely as long as it doesn't violate any DT or driver constraints. That way allowing reparenting doesn't need to be an all-or-nothing thing, and it doesn't need to be decided at the clock driver level with special flags. Regards, Aidan >> > Signed-off-by: Maxime Ripard >> > --- >> > drivers/clk/ingenic/cgu.c | 15 ++++++++------- >> > 1 file changed, 8 insertions(+), 7 deletions(-) >> > >> > diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c >> > index 1f7ba30f5a1b..0c9c8344ad11 100644 >> > --- a/drivers/clk/ingenic/cgu.c >> > +++ b/drivers/clk/ingenic/cgu.c >> > @@ -491,22 +491,23 @@ ingenic_clk_calc_div(struct clk_hw *hw, >> > return div; >> > } >> > >> > -static long >> > -ingenic_clk_round_rate(struct clk_hw *hw, unsigned long req_rate, >> > - unsigned long *parent_rate) >> > +static int ingenic_clk_determine_rate(struct clk_hw *hw, >> > + struct clk_rate_request *req) >> > { >> > struct ingenic_clk *ingenic_clk =3D to_ingenic_clk(hw); >> > const struct ingenic_cgu_clk_info *clk_info =3D >> > to_clk_info(ingenic_clk); >> > unsigned int div =3D 1; >> > >> > if (clk_info->type & CGU_CLK_DIV) >> > - div =3D ingenic_clk_calc_div(hw, clk_info, *parent_rate, req_rate); >> > + div =3D ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate, >> > + req->rate); >> >> Sorry but I'm not sure that this works. >> >> You replace the "parent_rate" with the "best_parent_rate", and that means >> you only check the requested rate vs. the parent with the highest freque= ncy, >> and not vs. the actual parent that will be used. > > best_parent_rate is initialized to the current parent rate, not the > parent with the highest frequency: > https://elixir.bootlin.com/linux/v6.1-rc3/source/drivers/clk/clk.c#L1471 > > Maxime 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 BCF29C4332F for ; Fri, 4 Nov 2022 18:11:33 +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=rGTgQRTvJ7+wpwlkKMLLuJ2D2RJ5LLC2QiImyoc9qek=; b=ONvdfgXxCS0SfZ 5OW4CT3icuDm7ue4SPZxvzgj/b1ba0eY/9yQTcwcq0ETHL7+wlht6I4gXSei+n9RxRXdfLd8YGwZu ei6aLVNNee7tTiD9l4Cr8VvuKaOzjMOi+nNc7zz7synUJMLaIr46NQa/zO2EecrYVJSQgy+IFaKoo Lt5rsM0VzrOcl0cxGipypek91D+GAB2wvq/aK5aAiF3DT6gRDxz5d0VW77uCSS++2o/jSvdeaVey1 NN+PU5LuGWWBA+rQb1TBTt+beHB23hpER1AKI6DiB3cxb2d0hTPJmx1JglplWwQcK88lJD3YUYs7Q +n8IF0X+E8+eDZODfXOw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1or1AC-004kUE-Vx; Fri, 04 Nov 2022 18:11:33 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1or1A7-004kT1-L4; Fri, 04 Nov 2022 18:11:30 +0000 Received: by mail-wm1-x32c.google.com with SMTP id p16so3476211wmc.3; Fri, 04 Nov 2022 11:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:from:to:cc:subject:date:message-id :reply-to; bh=CgAHyV5MssUU8DmgqTLqByPHjrUlZTpRzsXy7QZTV1w=; b=m1k1aGhFcGwAzy8+jR8i8dgnxBKgmbv+HEcBN9clOnBC8JDxQ1WLH/jaC98+SUuhn1 ojpUIvzLvAjOEtONQNG3fEjMYr6YmyE21HCNBu13dHQQCKT1MZYzip/HLcRMuJacgFsk D55A4srqhE9k1graGmYJvC73InZQsK8+3y7hORWhx8V9sPZvLSdaAKZue8yFET0sqAK6 QCfmTlWLBXdiCGceVK43T3rcfW1aWRAA7EsaVybuem8YgF0fY+TkmF3j/WgfSTXHeBZr 9yfwVW6BUgHERrFBi1RgnqxfwanJH3Intmfl0rdZ0bNVoL/stqFGyIUMqw38czj+U/IY +ZRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=CgAHyV5MssUU8DmgqTLqByPHjrUlZTpRzsXy7QZTV1w=; b=79GoWja4NB2dgfrQiAwynwE22mT+oibb+4zxV7xF03ivMjhXrCBxpX9oQOqNPCSWrU bDNEMSYw580FwwaHKGpmSYXfD27SGdislTqEQYXyrIiijAHafK/cS63IGZpxTHo7+rPL Xvz5QCP4LUOymau38gBcW7NE/C7PgvydjBWHSQv/XJf9Id0EiMZUVlHUbjkoJv9njDV7 XjGuqeFt0BFxdFE19nVCm4P1DyJw71iGTsXMci2XPwIZmjGokZLT48r+9l4agohUwQUD NE6Pw8rQjTvu01OtbblF+vaSkWwdG0YumF1x3PWtxfgwfwffnZCLUzq0Kua1eXtohfFi CS6Q== X-Gm-Message-State: ACrzQf2Hl1wZK1lXLchraPvovl8Nxmg9GLekvZBkGhBNjPh3cCLoN27m wooxv3KYl2V3CMkXomldgZ4= X-Google-Smtp-Source: AMsMyM5+00Cvx4Zit5cSiVEHfTNn4dr0i6mIADmjwE6QFA7y0/yyBqq7C4ech+m2YPARidv5n/8G+w== X-Received: by 2002:a05:600c:21c9:b0:3cf:68f8:7901 with SMTP id x9-20020a05600c21c900b003cf68f87901mr283147wmj.69.1667585484372; Fri, 04 Nov 2022 11:11:24 -0700 (PDT) Received: from localhost (94.197.10.32.threembb.co.uk. [94.197.10.32]) by smtp.gmail.com with ESMTPSA id az2-20020adfe182000000b00226dba960b4sm36409wrb.3.2022.11.04.11.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 11:11:23 -0700 (PDT) References: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> <20221018-clk-range-checks-fixes-v2-56-f6736dec138e@cerno.tech> <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> From: Aidan MacDonald To: Maxime Ripard Cc: Paul Cercueil , Stephen Boyd , Maxime Coquelin , Chen-Yu Tsai , Daniel Vetter , Nicolas Ferre , Thierry Reding , Jaroslav Kysela , Shawn Guo , Fabio Estevam , Ulf Hansson , Claudiu Beznea , Michael Turquette , Dinh Nguyen , Chunyan Zhang , Manivannan Sadhasivam , Andreas =?utf-8?Q?F=C3=A4rber?= , Jonathan Hunter , Abel Vesa , Charles Keepax , Alessandro Zummo , Peter De Schrijver , Orson Zhai , Alexandre Torgue , Prashant Gaikwad , Liam Girdwood , Alexandre Belloni , Samuel Holland , Matthias Brugger , Richard Fitzgerald , Vinod Koul , NXP Linux Team , Sekhar Nori , Kishon Vijay Abraham I , Linus Walleij , Takashi Iwai , David Airlie , Luca Ceresoli , Jernej Skrabec , Pengutronix Kernel Team , Baolin Wang , David Lechner , Sascha Hauer , Mark Brown , Max Filippov , Geert Uytterhoeven , linux-stm32@st-md-mailman.stormreply.com, alsa-devel@alsa-project.org, linux-mediatek@lists.infradead.org, linux-phy@lists.infradead.org, linux-mips@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-actions@lists.infradead.org, linux-clk@vger.kernel.org, AngeloGioacchino Del Regno , patches@opensource.cirrus.com, linux-tegra@vger.kernel.org, linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate Date: Fri, 04 Nov 2022 17:35:29 +0000 In-reply-to: <20221104145946.orsyrhiqvypisl5j@houat> Message-ID: MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221104_111127_716627_FFFB4CF4 X-CRM114-Status: GOOD ( 43.50 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org Ck1heGltZSBSaXBhcmQgPG1heGltZUBjZXJuby50ZWNoPiB3cml0ZXM6Cgo+IEhpIFBhdWwsCj4K PiBPbiBGcmksIE5vdiAwNCwgMjAyMiBhdCAwMjozMToyMFBNICswMDAwLCBQYXVsIENlcmN1ZWls IHdyb3RlOgo+PiBMZSB2ZW4uIDQgbm92LiAyMDIyIMOgIDE0OjE4OjEzICswMTAwLCBNYXhpbWUg UmlwYXJkIDxtYXhpbWVAY2Vybm8udGVjaD4gYQo+PiDDqWNyaXQgOgo+PiA+IFRoZSBJbmdlbmlj IENHVSBjbG9ja3MgaW1wbGVtZW50cyBhIG11eCB3aXRoIGEgc2V0X3BhcmVudCBob29rLCBidXQK Pj4gPiBkb2Vzbid0IHByb3ZpZGUgYSBkZXRlcm1pbmVfcmF0ZSBpbXBsZW1lbnRhdGlvbi4KPj4g Pgo+PiA+IFRoaXMgaXMgYSBiaXQgb2RkLCBzaW5jZSBzZXRfcGFyZW50KCkgaXMgdGhlcmUgdG8s IGFzIGl0cyBuYW1lIGltcGxpZXMsCj4+ID4gY2hhbmdlIHRoZSBwYXJlbnQgb2YgYSBjbG9jay4g SG93ZXZlciwgdGhlIG1vc3QgbGlrZWx5IGNhbmRpZGF0ZSB0bwo+PiA+IHRyaWdnZXIgdGhhdCBw YXJlbnQgY2hhbmdlIGlzIGEgY2FsbCB0byBjbGtfc2V0X3JhdGUoKSwgd2l0aAo+PiA+IGRldGVy bWluZV9yYXRlKCkgZmlndXJpbmcgb3V0IHdoaWNoIHBhcmVudCBpcyB0aGUgYmVzdCBzdWl0ZWQg Zm9yIGEKPj4gPiBnaXZlbiByYXRlLgo+PiA+Cj4+ID4gVGhlIG90aGVyIHRyaWdnZXIgd291bGQg YmUgYSBjYWxsIHRvIGNsa19zZXRfcGFyZW50KCksIGJ1dCBpdCdzIGZhciBsZXNzCj4+ID4gdXNl ZCwgYW5kIGl0IGRvZXNuJ3QgbG9vayBsaWtlIHRoZXJlJ3MgYW55IG9idmlvdXMgdXNlciBmb3Ig dGhhdCBjbG9jay4KPj4gPgo+PiA+IFNvLCB0aGUgc2V0X3BhcmVudCBob29rIGlzIGVmZmVjdGl2 ZWx5IHVudXNlZCwgcG9zc2libHkgYmVjYXVzZSBvZiBhbgo+PiA+IG92ZXJzaWdodC4gSG93ZXZl ciwgaXQgY291bGQgYWxzbyBiZSBhbiBleHBsaWNpdCBkZWNpc2lvbiBieSB0aGUKPj4gPiBvcmln aW5hbCBhdXRob3IgdG8gYXZvaWQgYW55IHJlcGFyZW50aW5nIGJ1dCB0aHJvdWdoIGFuIGV4cGxp Y2l0IGNhbGwgdG8KPj4gPiBjbGtfc2V0X3BhcmVudCgpLgo+PiA+Cj4+ID4gVGhlIGRyaXZlciBk b2VzIGltcGxlbWVudCByb3VuZF9yYXRlKCkgdGhvdWdoLCB3aGljaCBtZWFucyB0aGF0IHdlIGNh bgo+PiA+IGNoYW5nZSB0aGUgcmF0ZSBvZiB0aGUgY2xvY2ssIGJ1dCB3ZSB3aWxsIG5ldmVyIGdl dCB0byBjaGFuZ2UgdGhlCj4+ID4gcGFyZW50Lgo+PiA+Cj4+ID4gSG93ZXZlciwgSXQncyBoYXJk IHRvIHRlbGwgd2hldGhlciBpdCdzIGJlZW4gZG9uZSBvbiBwdXJwb3NlIG9yIG5vdC4KPj4gPgo+ PiA+IFNpbmNlIHdlJ2xsIHN0YXJ0IG1hbmRhdGluZyBhIGRldGVybWluZV9yYXRlKCkgaW1wbGVt ZW50YXRpb24sIGxldCdzCj4+ID4gY29udmVydCB0aGUgcm91bmRfcmF0ZSgpIGltcGxlbWVudGF0 aW9uIHRvIGEgZGV0ZXJtaW5lX3JhdGUoKSwgd2hpY2gKPj4gPiB3aWxsIGFsc28gbWFrZSB0aGUg Y3VycmVudCBiZWhhdmlvciBleHBsaWNpdC4gQW5kIGlmIGl0IHdhcyBhbgo+PiA+IG92ZXJzaWdo dCwgdGhlIGNsb2NrIGJlaGF2aW91ciBjYW4gYmUgYWRqdXN0ZWQgbGF0ZXIgb24uCj4+Cj4+IFNv IGl0J3MgcGFydGx5IG9uIHB1cnBvc2UsIHBhcnRseSBiZWNhdXNlIEkgZGlkbid0IGtub3cgYWJv dXQKPj4gLmRldGVybWluZV9yYXRlLgo+Pgo+PiBUaGVyZSdzIG5vdGhpbmcgb2RkIGFib3V0IGhh dmluZyBhIGxvbmVseSAuc2V0X3BhcmVudCBjYWxsYmFjazsgaW4gbXkgY2FzZQo+PiB0aGUgY2xv Y2tzIGFyZSBwYXJlbnRlZCBmcm9tIHRoZSBkZXZpY2UgdHJlZS4KPj4KPj4gSGF2aW5nIHRoZSBj bG9ja3MgZHJpdmVyIHRyaWdnZXIgYSBwYXJlbnQgY2hhbmdlIHdoZW4gcmVxdWVzdGluZyBhIHJh dGUKPj4gY2hhbmdlIHNvdW5kcyB2ZXJ5IGRhbmdlcm91cywgSU1ITy4gTXkgTU1DIGNvbnRyb2xs ZXIgY2FuIGJlIHBhcmVudGVkIHRvIHRoZQo+PiBleHRlcm5hbCA0OCBNSHogb3NjaWxsYXRvciwg YW5kIGlmIHRoZSBjYXJkIHJlcXVlc3RzIDUwIE1IeiwgaXQgY291bGQgc3dpdGNoCj4+IHRvIG9u ZSBvZiB0aGUgUExMcy4gVGhhdCB3b3JrcyBhcyBsb25nIGFzIHRoZSBQTExzIGRvbid0IGNoYW5n ZSByYXRlLCBidXQgaWYKPj4gb25lIGlzIGNvbmZpZ3VyZWQgYXMgZHJpdmluZyB0aGUgQ1BVIGNs b2NrLCBpdCBiZWNvbWVzIG1lc3N5Lgo+PiBUaGUgdGhpbmcgaXMsIHRoZSBjbG9ja3MgZHJpdmVy IGhhcyBubyB3YXkgdG8ga25vdyB3aGV0aGVyIG9yIG5vdCBpdCBpcwo+PiAic2FmZSIgdG8gdXNl IGEgZGVzaWduYXRlZCBwYXJlbnQuCj4+Cj4+IEZvciB0aGF0IHJlYXNvbiwgaW4gcHJhY3RpY2Us IEkgbmV2ZXIgYWN0dWFsbHkgd2FudCB0byBoYXZlIGEgY2xvY2sKPj4gcmUtcGFyZW50ZWQgLSBp dCdzIGFsbW9zdCBhbHdheXMgYSBiYWQgaWRlYSB2cy4gc3RpY2tpbmcgdG8gdGhlIHBhcmVudCBj bG9jawo+PiBjb25maWd1cmVkIGluIHRoZSBEVFMuCj4KPiBZZWFoLCBhbmQgdGhpcyBpcyB0b3Rh bGx5IGZpbmUuIEJ1dCB3ZSBuZWVkIHRvIGJlIGV4cGxpY2l0IGFib3V0IGl0LiBUaGUKPiBkZXRl cm1pbmVfcmF0ZSBpbXBsZW1lbnRhdGlvbiBJIGRpZCBpbiBhbGwgdGhlIHBhdGNoZXMgaXMgYW4g ZXhhY3QKPiBlcXVpdmFsZW50IHRvIHRoZSByb3VuZF9yYXRlIG9uZSBpZiB0aGVyZSB3YXMgb25l LiBXZSB3aWxsIG5ldmVyIGFzayB0bwo+IGNoYW5nZSB0aGUgcGFyZW50Lgo+Cj4gR2l2ZW4gd2hh dCB5b3UganVzdCBzYWlkLCBJIHdvdWxkIHN1Z2dlc3QgdG8gc2V0IHRoZQo+IENMS19TRVRfUkFU RV9OT19SRVBBUkVOVCBmbGFnIGFzIHdlbGwuCj4KCklkZWFsbHkgdGhlcmUgc2hvdWxkIGJlIGEg d2F5IGZvciBkcml2ZXJzIGFuZCB0aGUgZGV2aWNlIHRyZWUgdG8Kc2F5LCAiY2xvY2sgWCBtdXN0 IGJlIGRyaXZlbiBieSBjbG9jayBZIiwgYnV0IHRoZSBjbG9jayBmcmFtZXdvcmsKd291bGQgYmUg YWxsb3dlZCB0byByZS1wYXJlbnQgY2xvY2tzIGZyZWVseSBhcyBsb25nIGFzIGl0IGRvZXNuJ3QK dmlvbGF0ZSBhbnkgRFQgb3IgZHJpdmVyIGNvbnN0cmFpbnRzLgoKVGhhdCB3YXkgYWxsb3dpbmcg cmVwYXJlbnRpbmcgZG9lc24ndCBuZWVkIHRvIGJlIGFuIGFsbC1vci1ub3RoaW5nCnRoaW5nLCBh bmQgaXQgZG9lc24ndCBuZWVkIHRvIGJlIGRlY2lkZWQgYXQgdGhlIGNsb2NrIGRyaXZlciBsZXZl bAp3aXRoIHNwZWNpYWwgZmxhZ3MuCgpSZWdhcmRzLApBaWRhbgoKPj4gPiBTaWduZWQtb2ZmLWJ5 OiBNYXhpbWUgUmlwYXJkIDxtYXhpbWVAY2Vybm8udGVjaD4KPj4gPiAtLS0KPj4gPiAgZHJpdmVy cy9jbGsvaW5nZW5pYy9jZ3UuYyB8IDE1ICsrKysrKysrLS0tLS0tLQo+PiA+ICAxIGZpbGUgY2hh bmdlZCwgOCBpbnNlcnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQo+PiA+Cj4+ID4gZGlmZiAtLWdp dCBhL2RyaXZlcnMvY2xrL2luZ2VuaWMvY2d1LmMgYi9kcml2ZXJzL2Nsay9pbmdlbmljL2NndS5j Cj4+ID4gaW5kZXggMWY3YmEzMGY1YTFiLi4wYzljODM0NGFkMTEgMTAwNjQ0Cj4+ID4gLS0tIGEv ZHJpdmVycy9jbGsvaW5nZW5pYy9jZ3UuYwo+PiA+ICsrKyBiL2RyaXZlcnMvY2xrL2luZ2VuaWMv Y2d1LmMKPj4gPiBAQCAtNDkxLDIyICs0OTEsMjMgQEAgaW5nZW5pY19jbGtfY2FsY19kaXYoc3Ry dWN0IGNsa19odyAqaHcsCj4+ID4gIAlyZXR1cm4gZGl2Owo+PiA+ICB9Cj4+ID4KPj4gPiAtc3Rh dGljIGxvbmcKPj4gPiAtaW5nZW5pY19jbGtfcm91bmRfcmF0ZShzdHJ1Y3QgY2xrX2h3ICpodywg dW5zaWduZWQgbG9uZyByZXFfcmF0ZSwKPj4gPiAtCQkgICAgICAgdW5zaWduZWQgbG9uZyAqcGFy ZW50X3JhdGUpCj4+ID4gK3N0YXRpYyBpbnQgaW5nZW5pY19jbGtfZGV0ZXJtaW5lX3JhdGUoc3Ry dWN0IGNsa19odyAqaHcsCj4+ID4gKwkJCQkgICAgICBzdHJ1Y3QgY2xrX3JhdGVfcmVxdWVzdCAq cmVxKQo+PiA+ICB7Cj4+ID4gIAlzdHJ1Y3QgaW5nZW5pY19jbGsgKmluZ2VuaWNfY2xrID0gdG9f aW5nZW5pY19jbGsoaHcpOwo+PiA+ICAJY29uc3Qgc3RydWN0IGluZ2VuaWNfY2d1X2Nsa19pbmZv ICpjbGtfaW5mbyA9Cj4+ID4gdG9fY2xrX2luZm8oaW5nZW5pY19jbGspOwo+PiA+ICAJdW5zaWdu ZWQgaW50IGRpdiA9IDE7Cj4+ID4KPj4gPiAgCWlmIChjbGtfaW5mby0+dHlwZSAmIENHVV9DTEtf RElWKQo+PiA+IC0JCWRpdiA9IGluZ2VuaWNfY2xrX2NhbGNfZGl2KGh3LCBjbGtfaW5mbywgKnBh cmVudF9yYXRlLCByZXFfcmF0ZSk7Cj4+ID4gKwkJZGl2ID0gaW5nZW5pY19jbGtfY2FsY19kaXYo aHcsIGNsa19pbmZvLCByZXEtPmJlc3RfcGFyZW50X3JhdGUsCj4+ID4gKwkJCQkJICAgcmVxLT5y YXRlKTsKPj4KPj4gU29ycnkgYnV0IEknbSBub3Qgc3VyZSB0aGF0IHRoaXMgd29ya3MuCj4+Cj4+ IFlvdSByZXBsYWNlIHRoZSAicGFyZW50X3JhdGUiIHdpdGggdGhlICJiZXN0X3BhcmVudF9yYXRl IiwgYW5kIHRoYXQgbWVhbnMKPj4geW91IG9ubHkgY2hlY2sgdGhlIHJlcXVlc3RlZCByYXRlIHZz LiB0aGUgcGFyZW50IHdpdGggdGhlIGhpZ2hlc3QgZnJlcXVlbmN5LAo+PiBhbmQgbm90IHZzLiB0 aGUgYWN0dWFsIHBhcmVudCB0aGF0IHdpbGwgYmUgdXNlZC4KPgo+IGJlc3RfcGFyZW50X3JhdGUg aXMgaW5pdGlhbGl6ZWQgdG8gdGhlIGN1cnJlbnQgcGFyZW50IHJhdGUsIG5vdCB0aGUKPiBwYXJl bnQgd2l0aCB0aGUgaGlnaGVzdCBmcmVxdWVuY3k6Cj4gaHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5j b20vbGludXgvdjYuMS1yYzMvc291cmNlL2RyaXZlcnMvY2xrL2Nsay5jI0wxNDcxCj4KPiBNYXhp bWUKCi0tIApsaW51eC1waHkgbWFpbGluZyBsaXN0CmxpbnV4LXBoeUBsaXN0cy5pbmZyYWRlYWQu b3JnCmh0dHBzOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXBo eQo= 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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 C1016C4332F for ; Sat, 5 Nov 2022 07:24:37 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id EBE4D173A; Sat, 5 Nov 2022 08:23:45 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz EBE4D173A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1667633076; bh=FSvt/ogOqRoAAZs/kH99voP0YQKwIr/MwIQEnHpqisM=; h=References:From:To:Subject:Date:In-reply-to:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=bEbI3QhzgR1Qy2m+8Crc113AuNPbq+qVd9xCU2zq7wWKNUW2O9acqEck4Dv5PtFJY WJ/eYw5618ZfUWq9RgTy3hnoMtRO0dR+afs46RTywBLStLsH8a7wjz2woh1e1h8E8x eJ31Zlt41G0nExyIXm9fk3lFAlyVgJVrD7PK/nng= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id A3F3FF80858; Sat, 5 Nov 2022 08:04:32 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 922ADF80431; Fri, 4 Nov 2022 19:11:32 +0100 (CET) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 553A7F801D5 for ; Fri, 4 Nov 2022 19:11:26 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 553A7F801D5 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="m1k1aGhF" Received: by mail-wm1-x32b.google.com with SMTP id t1so3471131wmi.4 for ; Fri, 04 Nov 2022 11:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:from:to:cc:subject:date:message-id :reply-to; bh=CgAHyV5MssUU8DmgqTLqByPHjrUlZTpRzsXy7QZTV1w=; b=m1k1aGhFcGwAzy8+jR8i8dgnxBKgmbv+HEcBN9clOnBC8JDxQ1WLH/jaC98+SUuhn1 ojpUIvzLvAjOEtONQNG3fEjMYr6YmyE21HCNBu13dHQQCKT1MZYzip/HLcRMuJacgFsk D55A4srqhE9k1graGmYJvC73InZQsK8+3y7hORWhx8V9sPZvLSdaAKZue8yFET0sqAK6 QCfmTlWLBXdiCGceVK43T3rcfW1aWRAA7EsaVybuem8YgF0fY+TkmF3j/WgfSTXHeBZr 9yfwVW6BUgHERrFBi1RgnqxfwanJH3Intmfl0rdZ0bNVoL/stqFGyIUMqw38czj+U/IY +ZRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=CgAHyV5MssUU8DmgqTLqByPHjrUlZTpRzsXy7QZTV1w=; b=fJtkk/GIhCv8EqflT/FNmLZL+cMQQCAd021r2lR/oeGsIRyTpMAs9S9A/U9SN95Dxy x2y/TVTGo9dtKKFK4yB6DjdwaSf6KaC73ejIbrA/Ad+cwKHZQqlBDmSnKVuSsGuZQ0zK oQkHOcDKdTS1vC3OQ3RZlccOerTe4a2AKPq/QeTON4uupMrYzr9jzorkg1AF5ewuT1MV HEyW5DJalXAC3ARoXM/4la0oJPTYKGYixzUP88KyxenshoG4KLXRNtA/rcU1DXj5zNs0 0kf3lcYaI4SSdjLbVQ8O89a2O+21qV/IMNbZUcKqKtdqH1uB7V4tNDtSh+RWyKESO4ZT +upA== X-Gm-Message-State: ACrzQf0IXeX16oDheFzeku49I3Ek7I5ViYV+thGm+A5QL+yoHpeeWfXr nX0c1p84ws56Cg4wD88Jcd0= X-Google-Smtp-Source: AMsMyM5+00Cvx4Zit5cSiVEHfTNn4dr0i6mIADmjwE6QFA7y0/yyBqq7C4ech+m2YPARidv5n/8G+w== X-Received: by 2002:a05:600c:21c9:b0:3cf:68f8:7901 with SMTP id x9-20020a05600c21c900b003cf68f87901mr283147wmj.69.1667585484372; Fri, 04 Nov 2022 11:11:24 -0700 (PDT) Received: from localhost (94.197.10.32.threembb.co.uk. [94.197.10.32]) by smtp.gmail.com with ESMTPSA id az2-20020adfe182000000b00226dba960b4sm36409wrb.3.2022.11.04.11.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 11:11:23 -0700 (PDT) References: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> <20221018-clk-range-checks-fixes-v2-56-f6736dec138e@cerno.tech> <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> From: Aidan MacDonald To: Maxime Ripard Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate Date: Fri, 04 Nov 2022 17:35:29 +0000 In-reply-to: <20221104145946.orsyrhiqvypisl5j@houat> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 05 Nov 2022 08:03:32 +0100 Cc: Ulf Hansson , Prashant Gaikwad , Alexandre Belloni , Liam Girdwood , Michael Turquette , Sekhar Nori , Alexandre Torgue , dri-devel@lists.freedesktop.org, Paul Cercueil , Max Filippov , Thierry Reding , linux-phy@lists.infradead.org, David Airlie , Fabio Estevam , linux-stm32@st-md-mailman.stormreply.com, Abel Vesa , Kishon Vijay Abraham I , Geert Uytterhoeven , Samuel Holland , Chunyan Zhang , Takashi Iwai , linux-tegra@vger.kernel.org, Jernej Skrabec , Jonathan Hunter , Chen-Yu Tsai , NXP Linux Team , Orson Zhai , linux-mips@vger.kernel.org, Luca Ceresoli , Linus Walleij , linux-rtc@vger.kernel.org, linux-clk@vger.kernel.org, Charles Keepax , Daniel Vetter , alsa-devel@alsa-project.org, Manivannan Sadhasivam , linux-kernel@vger.kernel.org, Sascha Hauer , linux-actions@lists.infradead.org, Richard Fitzgerald , Mark Brown , linux-mediatek@lists.infradead.org, Baolin Wang , Matthias Brugger , Pengutronix Kernel Team , linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno , Alessandro Zummo , linux-sunxi@lists.linux.dev, Stephen Boyd , patches@opensource.cirrus.com, Peter De Schrijver , Nicolas Ferre , Andreas =?utf-8?Q?F=C3=A4rber?= , linux-renesas-soc@vger.kernel.org, Dinh Nguyen , Vinod Koul , Maxime Coquelin , David Lechner , Shawn Guo , Claudiu Beznea X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Maxime Ripard writes: > Hi Paul, > > On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote: >> Le ven. 4 nov. 2022 =C3=A0 14:18:13 +0100, Maxime Ripard a >> =C3=A9crit : >> > The Ingenic CGU clocks implements a mux with a set_parent hook, but >> > doesn't provide a determine_rate implementation. >> > >> > This is a bit odd, since set_parent() is there to, as its name implies, >> > change the parent of a clock. However, the most likely candidate to >> > trigger that parent change is a call to clk_set_rate(), with >> > determine_rate() figuring out which parent is the best suited for a >> > given rate. >> > >> > The other trigger would be a call to clk_set_parent(), but it's far le= ss >> > used, and it doesn't look like there's any obvious user for that clock. >> > >> > So, the set_parent hook is effectively unused, possibly because of an >> > oversight. However, it could also be an explicit decision by the >> > original author to avoid any reparenting but through an explicit call = to >> > clk_set_parent(). >> > >> > The driver does implement round_rate() though, which means that we can >> > change the rate of the clock, but we will never get to change the >> > parent. >> > >> > However, It's hard to tell whether it's been done on purpose or not. >> > >> > Since we'll start mandating a determine_rate() implementation, let's >> > convert the round_rate() implementation to a determine_rate(), which >> > will also make the current behavior explicit. And if it was an >> > oversight, the clock behaviour can be adjusted later on. >> >> So it's partly on purpose, partly because I didn't know about >> .determine_rate. >> >> There's nothing odd about having a lonely .set_parent callback; in my ca= se >> the clocks are parented from the device tree. >> >> Having the clocks driver trigger a parent change when requesting a rate >> change sounds very dangerous, IMHO. My MMC controller can be parented to= the >> external 48 MHz oscillator, and if the card requests 50 MHz, it could sw= itch >> to one of the PLLs. That works as long as the PLLs don't change rate, bu= t if >> one is configured as driving the CPU clock, it becomes messy. >> The thing is, the clocks driver has no way to know whether or not it is >> "safe" to use a designated parent. >> >> For that reason, in practice, I never actually want to have a clock >> re-parented - it's almost always a bad idea vs. sticking to the parent c= lock >> configured in the DTS. > > Yeah, and this is totally fine. But we need to be explicit about it. The > determine_rate implementation I did in all the patches is an exact > equivalent to the round_rate one if there was one. We will never ask to > change the parent. > > Given what you just said, I would suggest to set the > CLK_SET_RATE_NO_REPARENT flag as well. > Ideally there should be a way for drivers and the device tree to say, "clock X must be driven by clock Y", but the clock framework would be allowed to re-parent clocks freely as long as it doesn't violate any DT or driver constraints. That way allowing reparenting doesn't need to be an all-or-nothing thing, and it doesn't need to be decided at the clock driver level with special flags. Regards, Aidan >> > Signed-off-by: Maxime Ripard >> > --- >> > drivers/clk/ingenic/cgu.c | 15 ++++++++------- >> > 1 file changed, 8 insertions(+), 7 deletions(-) >> > >> > diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c >> > index 1f7ba30f5a1b..0c9c8344ad11 100644 >> > --- a/drivers/clk/ingenic/cgu.c >> > +++ b/drivers/clk/ingenic/cgu.c >> > @@ -491,22 +491,23 @@ ingenic_clk_calc_div(struct clk_hw *hw, >> > return div; >> > } >> > >> > -static long >> > -ingenic_clk_round_rate(struct clk_hw *hw, unsigned long req_rate, >> > - unsigned long *parent_rate) >> > +static int ingenic_clk_determine_rate(struct clk_hw *hw, >> > + struct clk_rate_request *req) >> > { >> > struct ingenic_clk *ingenic_clk =3D to_ingenic_clk(hw); >> > const struct ingenic_cgu_clk_info *clk_info =3D >> > to_clk_info(ingenic_clk); >> > unsigned int div =3D 1; >> > >> > if (clk_info->type & CGU_CLK_DIV) >> > - div =3D ingenic_clk_calc_div(hw, clk_info, *parent_rate, req_rate); >> > + div =3D ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate, >> > + req->rate); >> >> Sorry but I'm not sure that this works. >> >> You replace the "parent_rate" with the "best_parent_rate", and that means >> you only check the requested rate vs. the parent with the highest freque= ncy, >> and not vs. the actual parent that will be used. > > best_parent_rate is initialized to the current parent rate, not the > parent with the highest frequency: > https://elixir.bootlin.com/linux/v6.1-rc3/source/drivers/clk/clk.c#L1471 > > Maxime 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 6D306C433FE for ; Sat, 5 Nov 2022 19:12:00 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 130DC10E00B; Sat, 5 Nov 2022 19:11:58 +0000 (UTC) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1129F10E986 for ; Fri, 4 Nov 2022 18:11:26 +0000 (UTC) Received: by mail-wm1-x335.google.com with SMTP id t1so3471130wmi.4 for ; Fri, 04 Nov 2022 11:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:from:to:cc:subject:date:message-id :reply-to; bh=CgAHyV5MssUU8DmgqTLqByPHjrUlZTpRzsXy7QZTV1w=; b=m1k1aGhFcGwAzy8+jR8i8dgnxBKgmbv+HEcBN9clOnBC8JDxQ1WLH/jaC98+SUuhn1 ojpUIvzLvAjOEtONQNG3fEjMYr6YmyE21HCNBu13dHQQCKT1MZYzip/HLcRMuJacgFsk D55A4srqhE9k1graGmYJvC73InZQsK8+3y7hORWhx8V9sPZvLSdaAKZue8yFET0sqAK6 QCfmTlWLBXdiCGceVK43T3rcfW1aWRAA7EsaVybuem8YgF0fY+TkmF3j/WgfSTXHeBZr 9yfwVW6BUgHERrFBi1RgnqxfwanJH3Intmfl0rdZ0bNVoL/stqFGyIUMqw38czj+U/IY +ZRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=CgAHyV5MssUU8DmgqTLqByPHjrUlZTpRzsXy7QZTV1w=; b=kcjxQ0v37xknCVhV049sisUtfSAFhrVDWyV52qABlPmw1ZTO3Xxv/+PswqFz5Llc3g M5k0nX6D+t7z5ZmdUw/rEfgJN6IA4THKk+qaLls+a30fZWdQXE4MbKjXaAEg+iowyx3R usnDKn3vy6V11gwtcFWtiJlUESm/7N7wHvFWH1PYDMrIU9SijVjHwlmGQ27ozkTRuJyN K0sPocCFSGKLAQNNDEC+owUD+lsFp6B84GTUIq8YaNb0WgPf5LToptvteCQZMQ97TCKQ hH0j1md/533/gcIenXHv6jogsE2yLCG3XTXcdR2Q/zEAlpSwCDVgb4nRmQN0YMvEmAvY +73w== X-Gm-Message-State: ACrzQf0x0Ip3RwvvMMjSa6Ox33fWJJL8YdyxsBjzX29ywJ4U5uVpTw/9 YLGT7PdroDV1Y4E6U7no8I4= X-Google-Smtp-Source: AMsMyM5+00Cvx4Zit5cSiVEHfTNn4dr0i6mIADmjwE6QFA7y0/yyBqq7C4ech+m2YPARidv5n/8G+w== X-Received: by 2002:a05:600c:21c9:b0:3cf:68f8:7901 with SMTP id x9-20020a05600c21c900b003cf68f87901mr283147wmj.69.1667585484372; Fri, 04 Nov 2022 11:11:24 -0700 (PDT) Received: from localhost (94.197.10.32.threembb.co.uk. [94.197.10.32]) by smtp.gmail.com with ESMTPSA id az2-20020adfe182000000b00226dba960b4sm36409wrb.3.2022.11.04.11.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 11:11:23 -0700 (PDT) References: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> <20221018-clk-range-checks-fixes-v2-56-f6736dec138e@cerno.tech> <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> From: Aidan MacDonald To: Maxime Ripard Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate Date: Fri, 04 Nov 2022 17:35:29 +0000 In-reply-to: <20221104145946.orsyrhiqvypisl5j@houat> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 05 Nov 2022 19:11:56 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , Prashant Gaikwad , Alexandre Belloni , Liam Girdwood , Michael Turquette , Sekhar Nori , Alexandre Torgue , dri-devel@lists.freedesktop.org, Jaroslav Kysela , Paul Cercueil , Max Filippov , Thierry Reding , linux-phy@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, Abel Vesa , Kishon Vijay Abraham I , Geert Uytterhoeven , Samuel Holland , Chunyan Zhang , Takashi Iwai , linux-tegra@vger.kernel.org, Jernej Skrabec , Jonathan Hunter , Chen-Yu Tsai , NXP Linux Team , Orson Zhai , linux-mips@vger.kernel.org, Luca Ceresoli , linux-rtc@vger.kernel.org, linux-clk@vger.kernel.org, Charles Keepax , alsa-devel@alsa-project.org, Manivannan Sadhasivam , linux-kernel@vger.kernel.org, Sascha Hauer , linux-actions@lists.infradead.org, Richard Fitzgerald , Mark Brown , linux-mediatek@lists.infradead.org, Baolin Wang , Matthias Brugger , Pengutronix Kernel Team , linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno , Alessandro Zummo , linux-sunxi@lists.linux.dev, Stephen Boyd , patches@opensource.cirrus.com, Peter De Schrijver , Nicolas Ferre , Andreas =?utf-8?Q?F=C3=A4rber?= , linux-renesas-soc@vger.kernel.org, Dinh Nguyen , Vinod Koul , Maxime Coquelin , David Lechner , Shawn Guo , Claudiu Beznea Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Maxime Ripard writes: > Hi Paul, > > On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote: >> Le ven. 4 nov. 2022 =C3=A0 14:18:13 +0100, Maxime Ripard a >> =C3=A9crit : >> > The Ingenic CGU clocks implements a mux with a set_parent hook, but >> > doesn't provide a determine_rate implementation. >> > >> > This is a bit odd, since set_parent() is there to, as its name implies, >> > change the parent of a clock. However, the most likely candidate to >> > trigger that parent change is a call to clk_set_rate(), with >> > determine_rate() figuring out which parent is the best suited for a >> > given rate. >> > >> > The other trigger would be a call to clk_set_parent(), but it's far le= ss >> > used, and it doesn't look like there's any obvious user for that clock. >> > >> > So, the set_parent hook is effectively unused, possibly because of an >> > oversight. However, it could also be an explicit decision by the >> > original author to avoid any reparenting but through an explicit call = to >> > clk_set_parent(). >> > >> > The driver does implement round_rate() though, which means that we can >> > change the rate of the clock, but we will never get to change the >> > parent. >> > >> > However, It's hard to tell whether it's been done on purpose or not. >> > >> > Since we'll start mandating a determine_rate() implementation, let's >> > convert the round_rate() implementation to a determine_rate(), which >> > will also make the current behavior explicit. And if it was an >> > oversight, the clock behaviour can be adjusted later on. >> >> So it's partly on purpose, partly because I didn't know about >> .determine_rate. >> >> There's nothing odd about having a lonely .set_parent callback; in my ca= se >> the clocks are parented from the device tree. >> >> Having the clocks driver trigger a parent change when requesting a rate >> change sounds very dangerous, IMHO. My MMC controller can be parented to= the >> external 48 MHz oscillator, and if the card requests 50 MHz, it could sw= itch >> to one of the PLLs. That works as long as the PLLs don't change rate, bu= t if >> one is configured as driving the CPU clock, it becomes messy. >> The thing is, the clocks driver has no way to know whether or not it is >> "safe" to use a designated parent. >> >> For that reason, in practice, I never actually want to have a clock >> re-parented - it's almost always a bad idea vs. sticking to the parent c= lock >> configured in the DTS. > > Yeah, and this is totally fine. But we need to be explicit about it. The > determine_rate implementation I did in all the patches is an exact > equivalent to the round_rate one if there was one. We will never ask to > change the parent. > > Given what you just said, I would suggest to set the > CLK_SET_RATE_NO_REPARENT flag as well. > Ideally there should be a way for drivers and the device tree to say, "clock X must be driven by clock Y", but the clock framework would be allowed to re-parent clocks freely as long as it doesn't violate any DT or driver constraints. That way allowing reparenting doesn't need to be an all-or-nothing thing, and it doesn't need to be decided at the clock driver level with special flags. Regards, Aidan >> > Signed-off-by: Maxime Ripard >> > --- >> > drivers/clk/ingenic/cgu.c | 15 ++++++++------- >> > 1 file changed, 8 insertions(+), 7 deletions(-) >> > >> > diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c >> > index 1f7ba30f5a1b..0c9c8344ad11 100644 >> > --- a/drivers/clk/ingenic/cgu.c >> > +++ b/drivers/clk/ingenic/cgu.c >> > @@ -491,22 +491,23 @@ ingenic_clk_calc_div(struct clk_hw *hw, >> > return div; >> > } >> > >> > -static long >> > -ingenic_clk_round_rate(struct clk_hw *hw, unsigned long req_rate, >> > - unsigned long *parent_rate) >> > +static int ingenic_clk_determine_rate(struct clk_hw *hw, >> > + struct clk_rate_request *req) >> > { >> > struct ingenic_clk *ingenic_clk =3D to_ingenic_clk(hw); >> > const struct ingenic_cgu_clk_info *clk_info =3D >> > to_clk_info(ingenic_clk); >> > unsigned int div =3D 1; >> > >> > if (clk_info->type & CGU_CLK_DIV) >> > - div =3D ingenic_clk_calc_div(hw, clk_info, *parent_rate, req_rate); >> > + div =3D ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate, >> > + req->rate); >> >> Sorry but I'm not sure that this works. >> >> You replace the "parent_rate" with the "best_parent_rate", and that means >> you only check the requested rate vs. the parent with the highest freque= ncy, >> and not vs. the actual parent that will be used. > > best_parent_rate is initialized to the current parent rate, not the > parent with the highest frequency: > https://elixir.bootlin.com/linux/v6.1-rc3/source/drivers/clk/clk.c#L1471 > > Maxime