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 1CA5EC74A5B for ; Wed, 29 Mar 2023 16:08:30 +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 42406886; Wed, 29 Mar 2023 18:07:38 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 42406886 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1680106108; bh=ipngeYgaSnaVbrM8xVYaNt0f4Bwuvba5Wixq45ybVuI=; h=References:From:To:Subject:Date:In-reply-to:CC:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=QEB3UfkJUexQy5yoFLXkTQEQvP6T+DE4Znui/W8tAcEPubBI5tf8GL+s/7fX9Ue2a eh4TlH4Sagnf7sGNkKW1oUj/TgE4TXD5Qvyt6E1u5qmPcH/o6xamVnte2kqC2PsBPx eQErKrTcS5ckh5A2GjKxep1DsgWemJp7xAshmN5Y= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 7977DF80589; Wed, 29 Mar 2023 18:06:02 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 166A8F802E8; Fri, 24 Mar 2023 23:04:08 +0100 (CET) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 AE3D8F80093 for ; Fri, 24 Mar 2023 23:03:56 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz AE3D8F80093 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=T3F8aNz2 Received: by mail-wr1-x429.google.com with SMTP id y14so3143736wrq.4 for ; Fri, 24 Mar 2023 15:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679695435; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :references:from:to:cc:subject:date:message-id:reply-to; bh=eQ3RSbBi4GxRzlwFNletxU5cxz92xG3Lj6FTyrjdc0o=; b=T3F8aNz2ox9uoURQlE0mq2sXW4z262BpvG7ZxRtAtIbFhPc/TQEpQM0a0SgR+TrqHO CLYGJXT6hxHwzdY9UN32CZG2dOkIF2LFvXUPmwkIF/2GkwmMW7kb6axItHjQcEjAF96P YoZ2Q3loL8sCvN2e52vHQqe+AQbmZyqmh9t2+HCpPytsWAA2sxbaBc61b92bJ1dDr0QQ Tdx2iHxB/Aa/m/jyDHMcs00O0mdizZduxSlMQxMVQw/7cAeVdYgYGEV+MFN8ajK6+qK2 SFuRxlx0kY19AQ86OkmU5aCJ9GqDDqrZ45+h67Pz4nAn4V4ElL3E8abtemphkRCVy/gF HzMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679695435; h=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=eQ3RSbBi4GxRzlwFNletxU5cxz92xG3Lj6FTyrjdc0o=; b=28zeYuvEU8ctDszdKhX1jtGJd77f0RAenBEup/50U0KwSAm0Tr8lgvyZJMApHp3Jgw 1Ak23mrQ677heuNwwffaOqDGmTqSIePJtl5P2au9UbLRKFAEaipenwZECm2IhH7akU9K o82P+nNUDYuGiCbplC+wg+h5AEEaoS07H1flHJ/NDTlNmmbDJ7h0QJO32Rhsd1cO9O4i ObEk+Mx3mCSEuK8IfJEIvFl6cmaiX/z5OAOlWveLTD9Llv724rEj8iAyjt2L3tfm72nu 6LewsPtY5GqKvFheMagrQbNZ/AKue2Y80WTIyh3wM1thGH3zhUuE2cdQC3x31HkLyaPy Vspg== X-Gm-Message-State: AAQBX9dSpN6q7/N4z3byDZZ2kVX5bILX5bUaBM8AXol1IWfKffWxdww2 y81WOpIHRnxBS7Q6EHfp96Q= X-Google-Smtp-Source: AKy350bTnEgVdoWb1kTWyTj04kbZ8RkYf2o8/EHnYZiiSg63myut6K0B/vHtQugbPkbZgvwsB8kF9A== X-Received: by 2002:adf:e905:0:b0:2ce:a096:3ff2 with SMTP id f5-20020adfe905000000b002cea0963ff2mr3187613wrm.63.1679695434807; Fri, 24 Mar 2023 15:03:54 -0700 (PDT) Received: from localhost (94.197.5.156.threembb.co.uk. [94.197.5.156]) by smtp.gmail.com with ESMTPSA id e9-20020adffc49000000b002be5bdbe40csm19237361wrs.27.2023.03.24.15.03.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Mar 2023 15:03:54 -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> <20221107085417.xrsh6xy3ouwdkp4z@houat> <20221109110045.j24vwkaq3s4yzoy3@houat> <06a293adc75990ed3e297b076fc38d8a.sboyd@kernel.org> <20230324111959.frjf4neopbs67ugd@houat> From: Aidan MacDonald To: Maxime Ripard Subject: Re: [PATCH v2 56/65] clk: ingenic: cgu: Switch to determine_rate Date: Fri, 24 Mar 2023 20:58:48 +0000 In-reply-to: <20230324111959.frjf4neopbs67ugd@houat> Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-MailFrom: aidanmacdonald.0x0@gmail.com 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: JNGEC5EECCTE5VZVTQY2UTR5P7XLUW3V X-Message-ID-Hash: JNGEC5EECCTE5VZVTQY2UTR5P7XLUW3V X-Mailman-Approved-At: Wed, 29 Mar 2023 16:05:52 +0000 CC: Stephen Boyd , Paul Cercueil , 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 =?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 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: Maxime Ripard writes: > On Thu, Mar 23, 2023 at 03:35:30PM +0000, Aidan MacDonald wrote: >> >> Stephen Boyd writes: >> >> > Quoting Maxime Ripard (2022-11-09 03:00:45) >> >> On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote: >> >> > >> >> > Maxime Ripard writes: >> >> > >> >> > > Hi, >> >> > > >> >> > > On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote: >> >> > >> >> > Assigning the parent clock in the DT works once, at boot, but going off >> >> > what you wrote in the commit message, if the clock driver has a >> >> > .determine_rate() implementation that *can* reparent clocks then it >> >> > probably *will* reparent them, and the DT assignment will be lost. >> >> >> >> Yes, indeed, but assigned-clock-parents never provided any sort of >> >> guarantee on whether or not the clock was allowed to reparent or not. >> >> It's just a one-off thing, right before probe, and a clk_set_parent() >> >> call at probe will override that just fine. >> >> >> >> Just like assigned-clock-rates isn't permanent. >> >> >> >> > What I'm suggesting is a runtime constraint that the clock subsystem >> >> > would enforce, and actively prevent drivers from changing the parent. >> >> > Either explicitly with clk_set_parent() or due to .determine_rate(). >> >> > >> >> > That way you could write a .determine_rate() implementation that *can* >> >> > select a better parent, but if the DT applies a constraint to fix the >> >> > clock to a particular parent, the clock subsystem will force that parent >> >> > to be used so you can be sure the clock is never reparented by accident. >> >> >> >> Yeah, that sounds like a good idea, and CLK_SET_RATE_NO_REPARENT isn't >> >> too far off from this, it's just ignored by clk_set_parent() for now. I >> >> guess we could rename CLK_SET_RATE_NO_REPARENT to CLK_NO_REPARENT, make >> >> clk_set_parent handle it, and set that flag whenever >> >> assigned-clock-parents is set on a clock. >> >> >> >> It's out of scope for this series though, and I certainly don't want to >> >> deal with all the regressions it might create :) >> >> >> > >> > This sounds like a new dt binding that says the assigned parent should >> > never change. It sounds sort of like gpio hogs. A clock-hogs binding? >> >> Ideally we want the clock driver to be able to reparent clocks freely >> to get the best rate. But we also need some control over that to stop >> consumers from being reparented in undesired ways. Eg. you might want >> to make sure the GPU gets its own PLL so it can be reclocked easily, >> and putting another device on the GPU's PLL could prevent that. >> >> The only way to achieve this today is (1) never do any reparenting in >> the clock driver; and (2) use assigned-clock-parents in the DT to set >> up the entire clock tree manually. >> >> Maxime said that (2) is basically wrong -- if assigned-clock-parents >> provides no guarantee on what the OS does "after boot" then the OS is >> pretty much free to ignore it. > > I didn't really say it's wrong, just that it never provided the > guarantee you expect it to provide. I can't really say whether it's an > issue or not on your platform. > > It's mostly unrelated to this series though, none of these patches > affect that behavior in one way or the other. I know. Sorry for derailing your patch :( >> 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: >> >> clock-parents-0 = <&clk1>, <&pll_c>; >> clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>; >> >> 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. >> >> 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. > > 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? > > Maxime 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. Why would you put such arbitrary limitations into the driver? They would be different from machine to machine, unless the clock tree is so simple there is only *one* meaningful way to configure it. 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).