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