From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from aposti.net (aposti.net [89.234.176.197]) (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 4104410F2 for ; Sat, 5 Nov 2022 10:34:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1667644455; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TDaskHbQLkzLxZhbc0A77T82ys2sKHjzGtgSbl/eTqE=; b=3fY3IZ0hJPiRN8vNazn9bcQMqR2JrjTIi9AXqwxwIe42aFOkSxs8/LodJeR17HX6gwP6nU mZNm0vTVRbGLApx4Wl/flL8cOh+VgCBw+PxQes5goKWi15jShjtTx3YJEDgMNwV2KlXCJe TCPPbMNaz+6Yvnpx7NfiTwQwJoNtT18= Date: Sat, 05 Nov 2022 10:33:54 +0000 From: Paul Cercueil Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate To: Maxime Ripard Cc: 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 =?iso-8859-1?q?F=E4rber?= , 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 Message-Id: In-Reply-To: <20221104145946.orsyrhiqvypisl5j@houat> 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> 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=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Maxime, Le ven. 4 nov. 2022 =E0 15:59:46 +0100, Maxime Ripard=20 a =E9crit : > Hi Paul, >=20 > On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote: >> Le ven. 4 nov. 2022 =E0 14:18:13 +0100, Maxime Ripard=20 >> a >> =E9crit : >> > The Ingenic CGU clocks implements a mux with a set_parent hook,=20 >> but >> > doesn't provide a determine_rate implementation. >> > >> > This is a bit odd, since set_parent() is there to, as its name=20 >> implies, >> > change the parent of a clock. However, the most likely candidate=20 >> to >> > trigger that parent change is a call to clk_set_rate(), with >> > determine_rate() figuring out which parent is the best suited for=20 >> a >> > given rate. >> > >> > The other trigger would be a call to clk_set_parent(), but it's=20 >> far less >> > used, and it doesn't look like there's any obvious user for that=20 >> clock. >> > >> > So, the set_parent hook is effectively unused, possibly because=20 >> of an >> > oversight. However, it could also be an explicit decision by the >> > original author to avoid any reparenting but through an explicit=20 >> call to >> > clk_set_parent(). >> > >> > The driver does implement round_rate() though, which means that=20 >> 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=20 >> not. >> > >> > Since we'll start mandating a determine_rate() implementation,=20 >> let's >> > convert the round_rate() implementation to a determine_rate(),=20 >> which >> > will also make the current behavior explicit. And if it was an >> > oversight, the clock behaviour can be adjusted later on. >>=20 >> So it's partly on purpose, partly because I didn't know about >> .determine_rate. >>=20 >> There's nothing odd about having a lonely .set_parent callback; in=20 >> my case >> the clocks are parented from the device tree. >>=20 >> Having the clocks driver trigger a parent change when requesting a=20 >> rate >> change sounds very dangerous, IMHO. My MMC controller can be=20 >> parented to the >> external 48 MHz oscillator, and if the card requests 50 MHz, it=20 >> could switch >> to one of the PLLs. That works as long as the PLLs don't change=20 >> rate, but 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=20 >> it is >> "safe" to use a designated parent. >>=20 >> 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=20 >> parent clock >> configured in the DTS. >=20 > Yeah, and this is totally fine. But we need to be explicit about it.=20 > 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=20 > to > change the parent. >=20 > Given what you just said, I would suggest to set the > CLK_SET_RATE_NO_REPARENT flag as well. But that would introduce policy into the driver... The fact that I=20 don't want the MMC parented to the PLLs, doesn't mean that it's an=20 invalid configuration per se. Cheers, -Paul >>=20 >> > 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,=20 >> req_rate); >> > + div =3D ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate, >> > + req->rate); >>=20 >> Sorry but I'm not sure that this works. >>=20 >> You replace the "parent_rate" with the "best_parent_rate", and that=20 >> means >> you only check the requested rate vs. the parent with the highest=20 >> frequency, >> and not vs. the actual parent that will be used. >=20 > 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 >=20 > 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 36DBAC4167D for ; Sat, 5 Nov 2022 10:34:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0A1F610E135; Sat, 5 Nov 2022 10:34:23 +0000 (UTC) Received: from aposti.net (aposti.net [89.234.176.197]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7DEC210E135 for ; Sat, 5 Nov 2022 10:34:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1667644455; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TDaskHbQLkzLxZhbc0A77T82ys2sKHjzGtgSbl/eTqE=; b=3fY3IZ0hJPiRN8vNazn9bcQMqR2JrjTIi9AXqwxwIe42aFOkSxs8/LodJeR17HX6gwP6nU mZNm0vTVRbGLApx4Wl/flL8cOh+VgCBw+PxQes5goKWi15jShjtTx3YJEDgMNwV2KlXCJe TCPPbMNaz+6Yvnpx7NfiTwQwJoNtT18= Date: Sat, 05 Nov 2022 10:33:54 +0000 From: Paul Cercueil Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate To: Maxime Ripard Message-Id: In-Reply-To: <20221104145946.orsyrhiqvypisl5j@houat> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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 , 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 =?iso-8859-1?q?F=E4rber?= , 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" Hi Maxime, Le ven. 4 nov. 2022 =E0 15:59:46 +0100, Maxime Ripard=20 a =E9crit : > Hi Paul, >=20 > On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote: >> Le ven. 4 nov. 2022 =E0 14:18:13 +0100, Maxime Ripard=20 >> a >> =E9crit : >> > The Ingenic CGU clocks implements a mux with a set_parent hook,=20 >> but >> > doesn't provide a determine_rate implementation. >> > >> > This is a bit odd, since set_parent() is there to, as its name=20 >> implies, >> > change the parent of a clock. However, the most likely candidate=20 >> to >> > trigger that parent change is a call to clk_set_rate(), with >> > determine_rate() figuring out which parent is the best suited for=20 >> a >> > given rate. >> > >> > The other trigger would be a call to clk_set_parent(), but it's=20 >> far less >> > used, and it doesn't look like there's any obvious user for that=20 >> clock. >> > >> > So, the set_parent hook is effectively unused, possibly because=20 >> of an >> > oversight. However, it could also be an explicit decision by the >> > original author to avoid any reparenting but through an explicit=20 >> call to >> > clk_set_parent(). >> > >> > The driver does implement round_rate() though, which means that=20 >> 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=20 >> not. >> > >> > Since we'll start mandating a determine_rate() implementation,=20 >> let's >> > convert the round_rate() implementation to a determine_rate(),=20 >> which >> > will also make the current behavior explicit. And if it was an >> > oversight, the clock behaviour can be adjusted later on. >>=20 >> So it's partly on purpose, partly because I didn't know about >> .determine_rate. >>=20 >> There's nothing odd about having a lonely .set_parent callback; in=20 >> my case >> the clocks are parented from the device tree. >>=20 >> Having the clocks driver trigger a parent change when requesting a=20 >> rate >> change sounds very dangerous, IMHO. My MMC controller can be=20 >> parented to the >> external 48 MHz oscillator, and if the card requests 50 MHz, it=20 >> could switch >> to one of the PLLs. That works as long as the PLLs don't change=20 >> rate, but 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=20 >> it is >> "safe" to use a designated parent. >>=20 >> 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=20 >> parent clock >> configured in the DTS. >=20 > Yeah, and this is totally fine. But we need to be explicit about it.=20 > 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=20 > to > change the parent. >=20 > Given what you just said, I would suggest to set the > CLK_SET_RATE_NO_REPARENT flag as well. But that would introduce policy into the driver... The fact that I=20 don't want the MMC parented to the PLLs, doesn't mean that it's an=20 invalid configuration per se. Cheers, -Paul >>=20 >> > 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,=20 >> req_rate); >> > + div =3D ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate, >> > + req->rate); >>=20 >> Sorry but I'm not sure that this works. >>=20 >> You replace the "parent_rate" with the "best_parent_rate", and that=20 >> means >> you only check the requested rate vs. the parent with the highest=20 >> frequency, >> and not vs. the actual parent that will be used. >=20 > 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 >=20 > 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 55172C433FE for ; Sat, 5 Nov 2022 10:34: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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-Id:Cc:To :Subject:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=tJ8Sw5yz6zsX7c7vts8u+rF1pHJ57P56IJmAzErm7a4=; b=Vx/6T6Wig7fDyg43URnDbM+n6r jAhaFOImrGcjrvzhCKfyTMF0dpxFBJLpBYHX72TJbeDxusAf8qn7MtjOJMR199Mk4uMNyNMCTz0nB aoH9I7YUB3x1seOGml+yGFXveiDb5HV819EMiBrhBQwNRCQbg+0cGZ8Ao6Un/HDEGF/8kOA28HRSO heAzYfpIKS4FwtoLOpOZrVgvyyRSUZYiPFieSe4eL8vtRNXVs+2ZdXe2JVioSubILJe43ecEq5bGS 79Gb3T/dX+Bo+Othw0TQlOVpa72cFUpay3ETJYWXqBIukloQtYGbToMAk18kfcUIR5iOeBzxB+ied h5EHWlHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1orGVU-006LMf-Ek; Sat, 05 Nov 2022 10:34:32 +0000 Received: from aposti.net ([89.234.176.197]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1orGVM-006LL4-OM; Sat, 05 Nov 2022 10:34:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1667644455; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TDaskHbQLkzLxZhbc0A77T82ys2sKHjzGtgSbl/eTqE=; b=3fY3IZ0hJPiRN8vNazn9bcQMqR2JrjTIi9AXqwxwIe42aFOkSxs8/LodJeR17HX6gwP6nU mZNm0vTVRbGLApx4Wl/flL8cOh+VgCBw+PxQes5goKWi15jShjtTx3YJEDgMNwV2KlXCJe TCPPbMNaz+6Yvnpx7NfiTwQwJoNtT18= Date: Sat, 05 Nov 2022 10:33:54 +0000 From: Paul Cercueil Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate To: Maxime Ripard Cc: 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 =?iso-8859-1?q?F=E4rber?= , 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 Message-Id: In-Reply-To: <20221104145946.orsyrhiqvypisl5j@houat> 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> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221105_033424_979306_3B90E201 X-CRM114-Status: GOOD ( 38.91 ) 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org Hi Maxime, Le ven. 4 nov. 2022 =E0 15:59:46 +0100, Maxime Ripard = a =E9crit : > Hi Paul, > = > On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote: >> Le ven. 4 nov. 2022 =E0 14:18:13 +0100, Maxime Ripard = >> a >> =E9crit : >> > 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 less >> > 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 case >> 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 switch >> to one of the PLLs. That works as long as the PLLs don't change = >> rate, but 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 clock >> 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. But that would introduce policy into the driver... The fact that I = don't want the MMC parented to the PLLs, doesn't mean that it's an = invalid configuration per se. Cheers, -Paul >> = >> > 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 = >> frequency, >> 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 -- = linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy 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 B1169C433FE for ; Wed, 9 Nov 2022 17:16:43 +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 E0992163A; Wed, 9 Nov 2022 18:15:51 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz E0992163A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1668014201; bh=VEF9nH+bDiK2Co4S+zlZK9hIWwwW3PPr6fDYmkOi8n4=; h=Date:From:Subject:To:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=SEW5sqS+gz7fpCSaOWoBG2NgKdRyq6EETl059I84dUinHHMcSeUBhmfOHhPJS34xO 8rkeJgNqjMyYoV7QBJ9vGzmfwNJTKul/Ak3i1g6l+SG2tPBWr2zIzoqlUXUUsIRlp1 YwtBW5C58mXPxCHQrSSPGKiDHbUCA7w+nw46b7Es= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 9D25DF800EC; Wed, 9 Nov 2022 18:15:51 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A13B3F803DC; Sat, 5 Nov 2022 11:34:22 +0100 (CET) Received: from aposti.net (aposti.net [89.234.176.197]) (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 8B8FCF801D5 for ; Sat, 5 Nov 2022 11:34:16 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8B8FCF801D5 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=crapouillou.net header.i=@crapouillou.net header.b="3fY3IZ0h" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1667644455; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TDaskHbQLkzLxZhbc0A77T82ys2sKHjzGtgSbl/eTqE=; b=3fY3IZ0hJPiRN8vNazn9bcQMqR2JrjTIi9AXqwxwIe42aFOkSxs8/LodJeR17HX6gwP6nU mZNm0vTVRbGLApx4Wl/flL8cOh+VgCBw+PxQes5goKWi15jShjtTx3YJEDgMNwV2KlXCJe TCPPbMNaz+6Yvnpx7NfiTwQwJoNtT18= Date: Sat, 05 Nov 2022 10:33:54 +0000 From: Paul Cercueil Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate To: Maxime Ripard Message-Id: In-Reply-To: <20221104145946.orsyrhiqvypisl5j@houat> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 09 Nov 2022 18:15:49 +0100 Cc: Ulf Hansson , Prashant Gaikwad , Alexandre Belloni , Liam Girdwood , Michael Turquette , Sekhar Nori , Alexandre Torgue , dri-devel@lists.freedesktop.org, 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 =?iso-8859-1?q?F=E4rber?= , 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" Hi Maxime, Le ven. 4 nov. 2022 =E0 15:59:46 +0100, Maxime Ripard=20 a =E9crit : > Hi Paul, >=20 > On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote: >> Le ven. 4 nov. 2022 =E0 14:18:13 +0100, Maxime Ripard=20 >> a >> =E9crit : >> > The Ingenic CGU clocks implements a mux with a set_parent hook,=20 >> but >> > doesn't provide a determine_rate implementation. >> > >> > This is a bit odd, since set_parent() is there to, as its name=20 >> implies, >> > change the parent of a clock. However, the most likely candidate=20 >> to >> > trigger that parent change is a call to clk_set_rate(), with >> > determine_rate() figuring out which parent is the best suited for=20 >> a >> > given rate. >> > >> > The other trigger would be a call to clk_set_parent(), but it's=20 >> far less >> > used, and it doesn't look like there's any obvious user for that=20 >> clock. >> > >> > So, the set_parent hook is effectively unused, possibly because=20 >> of an >> > oversight. However, it could also be an explicit decision by the >> > original author to avoid any reparenting but through an explicit=20 >> call to >> > clk_set_parent(). >> > >> > The driver does implement round_rate() though, which means that=20 >> 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=20 >> not. >> > >> > Since we'll start mandating a determine_rate() implementation,=20 >> let's >> > convert the round_rate() implementation to a determine_rate(),=20 >> which >> > will also make the current behavior explicit. And if it was an >> > oversight, the clock behaviour can be adjusted later on. >>=20 >> So it's partly on purpose, partly because I didn't know about >> .determine_rate. >>=20 >> There's nothing odd about having a lonely .set_parent callback; in=20 >> my case >> the clocks are parented from the device tree. >>=20 >> Having the clocks driver trigger a parent change when requesting a=20 >> rate >> change sounds very dangerous, IMHO. My MMC controller can be=20 >> parented to the >> external 48 MHz oscillator, and if the card requests 50 MHz, it=20 >> could switch >> to one of the PLLs. That works as long as the PLLs don't change=20 >> rate, but 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=20 >> it is >> "safe" to use a designated parent. >>=20 >> 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=20 >> parent clock >> configured in the DTS. >=20 > Yeah, and this is totally fine. But we need to be explicit about it.=20 > 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=20 > to > change the parent. >=20 > Given what you just said, I would suggest to set the > CLK_SET_RATE_NO_REPARENT flag as well. But that would introduce policy into the driver... The fact that I=20 don't want the MMC parented to the PLLs, doesn't mean that it's an=20 invalid configuration per se. Cheers, -Paul >>=20 >> > 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,=20 >> req_rate); >> > + div =3D ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate, >> > + req->rate); >>=20 >> Sorry but I'm not sure that this works. >>=20 >> You replace the "parent_rate" with the "best_parent_rate", and that=20 >> means >> you only check the requested rate vs. the parent with the highest=20 >> frequency, >> and not vs. the actual parent that will be used. >=20 > 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 >=20 > Maxime