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 72C7329B2 for ; Wed, 5 Apr 2023 13:06:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1680699450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Mq/p4txhSsRLR5xVgrA62YXfgD49tU+mOTycAeKgsHg=; b=Mb98f9ufodGaozAOY4xYrOH4ki7sxYY/vAA0bNDznfkO1jY7oQ7vUoy9gBV18sQyg7Fqkp 4iw1OtIZgkWKHd7enKxNHs2560FyoXBFO6izP6fR7+5aCxwEgm0s0Qni1/6h8kIbFM1q0N AxvQ9vdC4gf6sPGfRYLz7iOkrkLShI8= Message-ID: <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate From: Paul Cercueil To: Maxime Ripard , Aidan MacDonald 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 Date: Wed, 05 Apr 2023 14:57:26 +0200 In-Reply-To: <20230327192430.b2cp3yyrkzy4g4vw@penduick> References: <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> <20230327192430.b2cp3yyrkzy4g4vw@penduick> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Maxime, Le lundi 27 mars 2023 =C3=A0 21:24 +0200, Maxime Ripard a =C3=A9crit=C2=A0: > On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote: > > > > My suggestion: add a per-clock bitmap to keep track of which > > > > parents > > > > are allowed. Any operation that would select a parent clock not > > > > on the > > > > whitelist should fail. Automatic reparenting should only select > > > > from > > > > clocks on the whitelist. And we need new DT bindings for > > > > controlling > > > > the whitelist, for example: > > > >=20 > > > > =C2=A0=C2=A0=C2=A0 clock-parents-0 =3D <&clk1>, <&pll_c>; > > > > =C2=A0=C2=A0=C2=A0 clock-parents-1 =3D <&clk2>, <&pll_a>, <&pll_b>; > > > >=20 > > > > This means that clk1 can only have pll_c as a parent, while > > > > clk2 can > > > > have pll_a or pll_b as parents. By default every clock will be > > > > able > > > > to use any parent, so a list is only needed if the machine > > > > needs a > > > > more restrictive policy. > > > >=20 > > > > assigned-clock-parents should disable automatic reparenting, > > > > but allow > > > > explicit clk_set_parent(). This will allow clock drivers to > > > > start doing > > > > reparenting without breaking old DTs. > > >=20 > > > I'm generally not a fan of putting all these policies in the > > > device > > > tree. Do you have an example where it wouldn't be possible to do > > > exactly > > > this from the driver itself? > >=20 > > I'm confused. What's implicit in the example is clk1 and clk2 might > > have *other* possible choices of parent clock and the device tree > > is > > limiting what the OS is allowed to choose. > >=20 > > Why would you put such arbitrary limitations into the driver? >=20 > Why would we put such arbitrary limitations in the firmware? As this > entire thread can attest, people are already using the device tree to > work around the limitations of the Linux driver, or reduce the > features of Linux because they can rely on the device tree. Either > way, it's linked to the state of the Linux driver, and any other OS > or > Linux version could very well implement something more dynamic. Probably because if we have to choose between setting policy in the kernel or in the firmware, it is arguably better to set it in the firmware. Especially when talking about clocks, as the firmware is already the one programming the boot clocks. Cheers, -Paul > > They would be different from machine to machine, unless the clock > > tree is so simple there is only *one* meaningful way to configure > > it. >=20 > If we look at the device trees we have in-tree, most of the users of > assigned-clocks are the same from one board to another. >=20 > > Most SoCs are complicated enough that there will be tradeoffs > > depending on what peripherals you are using (typically a single > > machine will not use *every* peripheral device provided by the > > SoC). >=20 > We already have APIs to lock parents or rates on a given clock from > the consumer. It's far superior (feature-wise) than what the device > tree will ever offer because it's code, and it depends on the usage > already since an unused driver won't probe. >=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 A73F2C76188 for ; Wed, 5 Apr 2023 12:57:35 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D952A10E939; Wed, 5 Apr 2023 12:57:34 +0000 (UTC) Received: from aposti.net (aposti.net [89.234.176.197]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6F09810E939 for ; Wed, 5 Apr 2023 12:57:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1680699450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Mq/p4txhSsRLR5xVgrA62YXfgD49tU+mOTycAeKgsHg=; b=Mb98f9ufodGaozAOY4xYrOH4ki7sxYY/vAA0bNDznfkO1jY7oQ7vUoy9gBV18sQyg7Fqkp 4iw1OtIZgkWKHd7enKxNHs2560FyoXBFO6izP6fR7+5aCxwEgm0s0Qni1/6h8kIbFM1q0N AxvQ9vdC4gf6sPGfRYLz7iOkrkLShI8= Message-ID: <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate From: Paul Cercueil To: Maxime Ripard , Aidan MacDonald Date: Wed, 05 Apr 2023 14:57:26 +0200 In-Reply-To: <20230327192430.b2cp3yyrkzy4g4vw@penduick> References: <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> <20230327192430.b2cp3yyrkzy4g4vw@penduick> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 lundi 27 mars 2023 =C3=A0 21:24 +0200, Maxime Ripard a =C3=A9crit=C2=A0: > On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote: > > > > My suggestion: add a per-clock bitmap to keep track of which > > > > parents > > > > are allowed. Any operation that would select a parent clock not > > > > on the > > > > whitelist should fail. Automatic reparenting should only select > > > > from > > > > clocks on the whitelist. And we need new DT bindings for > > > > controlling > > > > the whitelist, for example: > > > >=20 > > > > =C2=A0=C2=A0=C2=A0 clock-parents-0 =3D <&clk1>, <&pll_c>; > > > > =C2=A0=C2=A0=C2=A0 clock-parents-1 =3D <&clk2>, <&pll_a>, <&pll_b>; > > > >=20 > > > > This means that clk1 can only have pll_c as a parent, while > > > > clk2 can > > > > have pll_a or pll_b as parents. By default every clock will be > > > > able > > > > to use any parent, so a list is only needed if the machine > > > > needs a > > > > more restrictive policy. > > > >=20 > > > > assigned-clock-parents should disable automatic reparenting, > > > > but allow > > > > explicit clk_set_parent(). This will allow clock drivers to > > > > start doing > > > > reparenting without breaking old DTs. > > >=20 > > > I'm generally not a fan of putting all these policies in the > > > device > > > tree. Do you have an example where it wouldn't be possible to do > > > exactly > > > this from the driver itself? > >=20 > > I'm confused. What's implicit in the example is clk1 and clk2 might > > have *other* possible choices of parent clock and the device tree > > is > > limiting what the OS is allowed to choose. > >=20 > > Why would you put such arbitrary limitations into the driver? >=20 > Why would we put such arbitrary limitations in the firmware? As this > entire thread can attest, people are already using the device tree to > work around the limitations of the Linux driver, or reduce the > features of Linux because they can rely on the device tree. Either > way, it's linked to the state of the Linux driver, and any other OS > or > Linux version could very well implement something more dynamic. Probably because if we have to choose between setting policy in the kernel or in the firmware, it is arguably better to set it in the firmware. Especially when talking about clocks, as the firmware is already the one programming the boot clocks. Cheers, -Paul > > They would be different from machine to machine, unless the clock > > tree is so simple there is only *one* meaningful way to configure > > it. >=20 > If we look at the device trees we have in-tree, most of the users of > assigned-clocks are the same from one board to another. >=20 > > Most SoCs are complicated enough that there will be tradeoffs > > depending on what peripherals you are using (typically a single > > machine will not use *every* peripheral device provided by the > > SoC). >=20 > We already have APIs to lock parents or rates on a given clock from > the consumer. It's far superior (feature-wise) than what the device > tree will ever offer because it's code, and it depends on the usage > already since an unused driver won't probe. >=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 66E4CC76188 for ; Wed, 5 Apr 2023 12:57:44 +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:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Qa+exgpJxndSf4SVYB2aIAZJG7S0Iz1vx6J2rrw8DxM=; b=VAYQaklZdpBXAx oEmQlzKBX7FC5Z776k8YzRt60e5FidwfBkpC1ZVfM9aNqnraMd1fclrqOlmRZmGI68G3k1Pgfhvfr AxiO4tgMXgamo4Ze2yIdnmrszO5UwBr2ogz6zP4fAmhip3hgGGscwysaHkj9fEbQ9JApeYGn3XwfL rqw8qsiUKJWigOUpS9W/tJyHYp9ujX3Dh24Sp02UeESTKMtRqsZ3mytRYQNTC8tydvsV0IT5XiXXp fVClcECZTSZVkf3Wj9XCBy4MBKoV3ml+WbJjS78FZwLG0VZ0Uwh7ch5xhK7A5xxtatTY4KHntTgxE GA2iV9EBGntO0ix3VZMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pk2hs-004SLO-0D; Wed, 05 Apr 2023 12:57:44 +0000 Received: from aposti.net ([89.234.176.197]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pk2hn-004SI0-1i; Wed, 05 Apr 2023 12:57:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1680699450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Mq/p4txhSsRLR5xVgrA62YXfgD49tU+mOTycAeKgsHg=; b=Mb98f9ufodGaozAOY4xYrOH4ki7sxYY/vAA0bNDznfkO1jY7oQ7vUoy9gBV18sQyg7Fqkp 4iw1OtIZgkWKHd7enKxNHs2560FyoXBFO6izP6fR7+5aCxwEgm0s0Qni1/6h8kIbFM1q0N AxvQ9vdC4gf6sPGfRYLz7iOkrkLShI8= Message-ID: <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate From: Paul Cercueil To: Maxime Ripard , Aidan MacDonald 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 Date: Wed, 05 Apr 2023 14:57:26 +0200 In-Reply-To: <20230327192430.b2cp3yyrkzy4g4vw@penduick> References: <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> <20230327192430.b2cp3yyrkzy4g4vw@penduick> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230405_055739_741624_B9697753 X-CRM114-Status: GOOD ( 41.35 ) 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 SGkgTWF4aW1lLAoKTGUgbHVuZGkgMjcgbWFycyAyMDIzIMOgIDIxOjI0ICswMjAwLCBNYXhpbWUg UmlwYXJkIGEgw6ljcml0wqA6Cj4gT24gRnJpLCBNYXIgMjQsIDIwMjMgYXQgMDg6NTg6NDhQTSAr MDAwMCwgQWlkYW4gTWFjRG9uYWxkIHdyb3RlOgo+ID4gPiA+IE15IHN1Z2dlc3Rpb246IGFkZCBh IHBlci1jbG9jayBiaXRtYXAgdG8ga2VlcCB0cmFjayBvZiB3aGljaAo+ID4gPiA+IHBhcmVudHMK PiA+ID4gPiBhcmUgYWxsb3dlZC4gQW55IG9wZXJhdGlvbiB0aGF0IHdvdWxkIHNlbGVjdCBhIHBh cmVudCBjbG9jayBub3QKPiA+ID4gPiBvbiB0aGUKPiA+ID4gPiB3aGl0ZWxpc3Qgc2hvdWxkIGZh aWwuIEF1dG9tYXRpYyByZXBhcmVudGluZyBzaG91bGQgb25seSBzZWxlY3QKPiA+ID4gPiBmcm9t Cj4gPiA+ID4gY2xvY2tzIG9uIHRoZSB3aGl0ZWxpc3QuIEFuZCB3ZSBuZWVkIG5ldyBEVCBiaW5k aW5ncyBmb3IKPiA+ID4gPiBjb250cm9sbGluZwo+ID4gPiA+IHRoZSB3aGl0ZWxpc3QsIGZvciBl eGFtcGxlOgo+ID4gPiA+IAo+ID4gPiA+IMKgwqDCoCBjbG9jay1wYXJlbnRzLTAgPSA8JmNsazE+ LCA8JnBsbF9jPjsKPiA+ID4gPiDCoMKgwqAgY2xvY2stcGFyZW50cy0xID0gPCZjbGsyPiwgPCZw bGxfYT4sIDwmcGxsX2I+Owo+ID4gPiA+IAo+ID4gPiA+IFRoaXMgbWVhbnMgdGhhdCBjbGsxIGNh biBvbmx5IGhhdmUgcGxsX2MgYXMgYSBwYXJlbnQsIHdoaWxlCj4gPiA+ID4gY2xrMiBjYW4KPiA+ ID4gPiBoYXZlIHBsbF9hIG9yIHBsbF9iIGFzIHBhcmVudHMuIEJ5IGRlZmF1bHQgZXZlcnkgY2xv Y2sgd2lsbCBiZQo+ID4gPiA+IGFibGUKPiA+ID4gPiB0byB1c2UgYW55IHBhcmVudCwgc28gYSBs aXN0IGlzIG9ubHkgbmVlZGVkIGlmIHRoZSBtYWNoaW5lCj4gPiA+ID4gbmVlZHMgYQo+ID4gPiA+ IG1vcmUgcmVzdHJpY3RpdmUgcG9saWN5Lgo+ID4gPiA+IAo+ID4gPiA+IGFzc2lnbmVkLWNsb2Nr LXBhcmVudHMgc2hvdWxkIGRpc2FibGUgYXV0b21hdGljIHJlcGFyZW50aW5nLAo+ID4gPiA+IGJ1 dCBhbGxvdwo+ID4gPiA+IGV4cGxpY2l0IGNsa19zZXRfcGFyZW50KCkuIFRoaXMgd2lsbCBhbGxv dyBjbG9jayBkcml2ZXJzIHRvCj4gPiA+ID4gc3RhcnQgZG9pbmcKPiA+ID4gPiByZXBhcmVudGlu ZyB3aXRob3V0IGJyZWFraW5nIG9sZCBEVHMuCj4gPiA+IAo+ID4gPiBJJ20gZ2VuZXJhbGx5IG5v dCBhIGZhbiBvZiBwdXR0aW5nIGFsbCB0aGVzZSBwb2xpY2llcyBpbiB0aGUKPiA+ID4gZGV2aWNl Cj4gPiA+IHRyZWUuIERvIHlvdSBoYXZlIGFuIGV4YW1wbGUgd2hlcmUgaXQgd291bGRuJ3QgYmUg cG9zc2libGUgdG8gZG8KPiA+ID4gZXhhY3RseQo+ID4gPiB0aGlzIGZyb20gdGhlIGRyaXZlciBp dHNlbGY/Cj4gPiAKPiA+IEknbSBjb25mdXNlZC4gV2hhdCdzIGltcGxpY2l0IGluIHRoZSBleGFt cGxlIGlzIGNsazEgYW5kIGNsazIgbWlnaHQKPiA+IGhhdmUgKm90aGVyKiBwb3NzaWJsZSBjaG9p Y2VzIG9mIHBhcmVudCBjbG9jayBhbmQgdGhlIGRldmljZSB0cmVlCj4gPiBpcwo+ID4gbGltaXRp bmcgd2hhdCB0aGUgT1MgaXMgYWxsb3dlZCB0byBjaG9vc2UuCj4gPiAKPiA+IFdoeSB3b3VsZCB5 b3UgcHV0IHN1Y2ggYXJiaXRyYXJ5IGxpbWl0YXRpb25zIGludG8gdGhlIGRyaXZlcj8KPiAKPiBX aHkgd291bGQgd2UgcHV0IHN1Y2ggYXJiaXRyYXJ5IGxpbWl0YXRpb25zIGluIHRoZSBmaXJtd2Fy ZT8gQXMgdGhpcwo+IGVudGlyZSB0aHJlYWQgY2FuIGF0dGVzdCwgcGVvcGxlIGFyZSBhbHJlYWR5 IHVzaW5nIHRoZSBkZXZpY2UgdHJlZSB0bwo+IHdvcmsgYXJvdW5kIHRoZSBsaW1pdGF0aW9ucyBv ZiB0aGUgTGludXggZHJpdmVyLCBvciByZWR1Y2UgdGhlCj4gZmVhdHVyZXMgb2YgTGludXggYmVj YXVzZSB0aGV5IGNhbiByZWx5IG9uIHRoZSBkZXZpY2UgdHJlZS4gRWl0aGVyCj4gd2F5LCBpdCdz IGxpbmtlZCB0byB0aGUgc3RhdGUgb2YgdGhlIExpbnV4IGRyaXZlciwgYW5kIGFueSBvdGhlciBP Uwo+IG9yCj4gTGludXggdmVyc2lvbiBjb3VsZCB2ZXJ5IHdlbGwgaW1wbGVtZW50IHNvbWV0aGlu ZyBtb3JlIGR5bmFtaWMuCgpQcm9iYWJseSBiZWNhdXNlIGlmIHdlIGhhdmUgdG8gY2hvb3NlIGJl dHdlZW4gc2V0dGluZyBwb2xpY3kgaW4gdGhlCmtlcm5lbCBvciBpbiB0aGUgZmlybXdhcmUsIGl0 IGlzIGFyZ3VhYmx5IGJldHRlciB0byBzZXQgaXQgaW4gdGhlCmZpcm13YXJlLgoKRXNwZWNpYWxs eSB3aGVuIHRhbGtpbmcgYWJvdXQgY2xvY2tzLCBhcyB0aGUgZmlybXdhcmUgaXMgYWxyZWFkeSB0 aGUKb25lIHByb2dyYW1taW5nIHRoZSBib290IGNsb2Nrcy4KCkNoZWVycywKLVBhdWwKCj4gPiBU aGV5IHdvdWxkIGJlIGRpZmZlcmVudCBmcm9tIG1hY2hpbmUgdG8gbWFjaGluZSwgdW5sZXNzIHRo ZSBjbG9jawo+ID4gdHJlZSBpcyBzbyBzaW1wbGUgdGhlcmUgaXMgb25seSAqb25lKiBtZWFuaW5n ZnVsIHdheSB0byBjb25maWd1cmUKPiA+IGl0Lgo+IAo+IElmIHdlIGxvb2sgYXQgdGhlIGRldmlj ZSB0cmVlcyB3ZSBoYXZlIGluLXRyZWUsIG1vc3Qgb2YgdGhlIHVzZXJzIG9mCj4gYXNzaWduZWQt Y2xvY2tzIGFyZSB0aGUgc2FtZSBmcm9tIG9uZSBib2FyZCB0byBhbm90aGVyLgo+IAo+ID4gTW9z dCBTb0NzIGFyZSBjb21wbGljYXRlZCBlbm91Z2ggdGhhdCB0aGVyZSB3aWxsIGJlIHRyYWRlb2Zm cwo+ID4gZGVwZW5kaW5nIG9uIHdoYXQgcGVyaXBoZXJhbHMgeW91IGFyZSB1c2luZyAodHlwaWNh bGx5IGEgc2luZ2xlCj4gPiBtYWNoaW5lIHdpbGwgbm90IHVzZSAqZXZlcnkqIHBlcmlwaGVyYWwg ZGV2aWNlIHByb3ZpZGVkIGJ5IHRoZQo+ID4gU29DKS4KPiAKPiBXZSBhbHJlYWR5IGhhdmUgQVBJ cyB0byBsb2NrIHBhcmVudHMgb3IgcmF0ZXMgb24gYSBnaXZlbiBjbG9jayBmcm9tCj4gdGhlIGNv bnN1bWVyLiBJdCdzIGZhciBzdXBlcmlvciAoZmVhdHVyZS13aXNlKSB0aGFuIHdoYXQgdGhlIGRl dmljZQo+IHRyZWUgd2lsbCBldmVyIG9mZmVyIGJlY2F1c2UgaXQncyBjb2RlLCBhbmQgaXQgZGVw ZW5kcyBvbiB0aGUgdXNhZ2UKPiBhbHJlYWR5IHNpbmNlIGFuIHVudXNlZCBkcml2ZXIgd29uJ3Qg cHJvYmUuCj4gCj4gTWF4aW1lCgoKLS0gCmxpbnV4LXBoeSBtYWlsaW5nIGxpc3QKbGludXgtcGh5 QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cHM6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4v bGlzdGluZm8vbGludXgtcGh5Cg== 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 303FFC76188 for ; Wed, 5 Apr 2023 14:38:43 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id C0EEB82E; Wed, 5 Apr 2023 16:37:50 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz C0EEB82E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1680705520; bh=Mq/p4txhSsRLR5xVgrA62YXfgD49tU+mOTycAeKgsHg=; h=Subject:From:To:Date:In-Reply-To:References:CC:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=lmLWZvCxFE8ODnWBW/vLjOX1M3D37UE5+nagFl1peKLoWTJeZ8vpIjteiF4ierCbx +1jn52lrVU+F0NW/eL1sQwC55e64hU5OF+s1A4Te6c/QS9JwrqsK1hHnlbmkaBp0DL TZMfxXCvxjhnjKcsE7jRbT0E5fSHLZByM7AyMQdQ= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id D0FD7F80558; Wed, 5 Apr 2023 16:36:21 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A0A69F801C0; Wed, 5 Apr 2023 14:57:42 +0200 (CEST) Received: from aposti.net (aposti.net [89.234.176.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id CE725F80249 for ; Wed, 5 Apr 2023 14:57:31 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz CE725F80249 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key, unprotected) header.d=crapouillou.net header.i=@crapouillou.net header.a=rsa-sha256 header.s=mail header.b=Mb98f9uf DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1680699450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Mq/p4txhSsRLR5xVgrA62YXfgD49tU+mOTycAeKgsHg=; b=Mb98f9ufodGaozAOY4xYrOH4ki7sxYY/vAA0bNDznfkO1jY7oQ7vUoy9gBV18sQyg7Fqkp 4iw1OtIZgkWKHd7enKxNHs2560FyoXBFO6izP6fR7+5aCxwEgm0s0Qni1/6h8kIbFM1q0N AxvQ9vdC4gf6sPGfRYLz7iOkrkLShI8= Message-ID: <1e0e8e9fe44c27e844e7e918a985704e58da2c27.camel@crapouillou.net> Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate From: Paul Cercueil To: Maxime Ripard , Aidan MacDonald Date: Wed, 05 Apr 2023 14:57:26 +0200 In-Reply-To: <20230327192430.b2cp3yyrkzy4g4vw@penduick> References: <80VTKR.CE8RVN8M3ZYK3@crapouillou.net> <20221104145946.orsyrhiqvypisl5j@houat> <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> <20230327192430.b2cp3yyrkzy4g4vw@penduick> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MailFrom: paul@crapouillou.net X-Mailman-Rule-Hits: max-recipients X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-size; news-moderation; no-subject; digests; suspicious-header Message-ID-Hash: 2FSSXM2NRD4T77F5X477WXBRULJPITTS X-Message-ID-Hash: 2FSSXM2NRD4T77F5X477WXBRULJPITTS X-Mailman-Approved-At: Wed, 05 Apr 2023 14:36:08 +0000 CC: Stephen Boyd , Maxime Coquelin , Chen-Yu Tsai , Daniel Vetter , Nicolas Ferre , Thierry Reding , 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 X-Mailman-Version: 3.3.8 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Maxime, Le lundi 27 mars 2023 =C3=A0 21:24 +0200, Maxime Ripard a =C3=A9crit=C2=A0: > On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote: > > > > My suggestion: add a per-clock bitmap to keep track of which > > > > parents > > > > are allowed. Any operation that would select a parent clock not > > > > on the > > > > whitelist should fail. Automatic reparenting should only select > > > > from > > > > clocks on the whitelist. And we need new DT bindings for > > > > controlling > > > > the whitelist, for example: > > > >=20 > > > > =C2=A0=C2=A0=C2=A0 clock-parents-0 =3D <&clk1>, <&pll_c>; > > > > =C2=A0=C2=A0=C2=A0 clock-parents-1 =3D <&clk2>, <&pll_a>, <&pll_b>; > > > >=20 > > > > This means that clk1 can only have pll_c as a parent, while > > > > clk2 can > > > > have pll_a or pll_b as parents. By default every clock will be > > > > able > > > > to use any parent, so a list is only needed if the machine > > > > needs a > > > > more restrictive policy. > > > >=20 > > > > assigned-clock-parents should disable automatic reparenting, > > > > but allow > > > > explicit clk_set_parent(). This will allow clock drivers to > > > > start doing > > > > reparenting without breaking old DTs. > > >=20 > > > I'm generally not a fan of putting all these policies in the > > > device > > > tree. Do you have an example where it wouldn't be possible to do > > > exactly > > > this from the driver itself? > >=20 > > I'm confused. What's implicit in the example is clk1 and clk2 might > > have *other* possible choices of parent clock and the device tree > > is > > limiting what the OS is allowed to choose. > >=20 > > Why would you put such arbitrary limitations into the driver? >=20 > Why would we put such arbitrary limitations in the firmware? As this > entire thread can attest, people are already using the device tree to > work around the limitations of the Linux driver, or reduce the > features of Linux because they can rely on the device tree. Either > way, it's linked to the state of the Linux driver, and any other OS > or > Linux version could very well implement something more dynamic. Probably because if we have to choose between setting policy in the kernel or in the firmware, it is arguably better to set it in the firmware. Especially when talking about clocks, as the firmware is already the one programming the boot clocks. Cheers, -Paul > > They would be different from machine to machine, unless the clock > > tree is so simple there is only *one* meaningful way to configure > > it. >=20 > If we look at the device trees we have in-tree, most of the users of > assigned-clocks are the same from one board to another. >=20 > > Most SoCs are complicated enough that there will be tradeoffs > > depending on what peripherals you are using (typically a single > > machine will not use *every* peripheral device provided by the > > SoC). >=20 > We already have APIs to lock parents or rates on a given clock from > the consumer. It's far superior (feature-wise) than what the device > tree will ever offer because it's code, and it depends on the usage > already since an unused driver won't probe. >=20 > Maxime