Date:   Wed, 29 Mar 2023 21:50:49 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Chen-Yu Tsai <wens@...e.org>, Daniel Vetter <daniel@...ll.ch>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Shawn Guo <shawnguo@...nel.org>,
        Fabio Estevam <festevam@...il.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Michael Turquette <mturquette@...libre.com>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Paul Cercueil <paul@...pouillou.net>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Andreas Färber <afaerber@...e.de>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Abel Vesa <abelvesa@...nel.org>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        Orson Zhai <orsonzhai@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Prashant Gaikwad <pgaikwad@...dia.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Samuel Holland <samuel@...lland.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Richard Fitzgerald <rf@...nsource.cirrus.com>,
        Vinod Koul <vkoul@...nel.org>,
        NXP Linux Team <linux-imx@....com>,
        Sekhar Nori <nsekhar@...com>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Takashi Iwai <tiwai@...e.com>,
        David Airlie <airlied@...il.com>,
        Luca Ceresoli <luca.ceresoli@...tlin.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        David Lechner <david@...hnology.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Max Filippov <jcmvbkbc@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        linux-stm32@...md-mailman.stormreply.com,
        alsa-devel@...a-project.org, linux-mediatek@...ts.infradead.org,
        linux-phy@...ts.infradead.org, linux-mips@...r.kernel.org,
        linux-renesas-soc@...r.kernel.org,
        linux-actions@...ts.infradead.org, linux-clk@...r.kernel.org,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        patches@...nsource.cirrus.com, linux-tegra@...r.kernel.org,
        linux-rtc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook

Hi Stephen,

On Wed, Mar 22, 2023 at 04:31:04PM -0700, Stephen Boyd wrote:
> > It's also replacing one implicit behavior by another. The point of this
> > series was to raise awareness on that particular point, so I'm not sure
> > it actually fixes things. We'll see what Stephen thinks about it.
> > 
> 
> Right. A decade ago (!) when determine_rate() was introduced we
> introduced CLK_SET_RATE_NO_REPARENT and set it on each mux user (see
> commit  819c1de344c5 ("clk: add CLK_SET_RATE_NO_REPARENT flag")). This
> way driver behavior wouldn't change and the status quo would be
> maintained, i.e. that clk_set_rate() on a mux wouldn't change parents.
> We didn't enforce that determine_rate exists if the set_parent() op
> existed at the same time though. Probably an oversight.
> 
> Most of the replies to this series have been "DT is setting the parent",
> which makes me believe that there are 'assigned-clock-parents' being
> used.

Yes, that's my understanding as well.

> The clk_set_parent() path is valid for those cases. Probably nobody
> cares about determine_rate because they don't set rates on these clks.
> Some drivers even explicitly left out determine_rate()/round_rate()
> because they didn't want to have some other clk round up to the mux
> and change the parent.
> 
> Eventually we want drivers to migrate to determine_rate op so we can get
> rid of the round_rate op and save a pointer (we're so greedy). It's been
> 10 years though, and that hasn't been done. Sigh! I can see value in
> this series from the angle of migrating, but adding a determine_rate op
> when there isn't a round_rate op makes it hard to reason about. What if
> something copies the clk_ops or sets a different flag? Now we've just
> added parent changing support to clk_set_rate(). What if the clk has
> CLK_SET_RATE_PARENT flag set? Now we're going to ask the parent clk to
> change rate. Fun bugs.
> 
> TL;DR: If the set_parent op exists but determine_rate/round_rate doesn't
> then the clk is a mux that doesn't want to support clk_set_rate(). Make
> a new mux function that's the contents of the CLK_SET_RATE_NO_REPARENT
> branch in clk_mux_determine_rate_flags() and call that directly from the
> clk_ops so it is clear what's happening,
> clk_hw_mux_same_parent_determine_rate() or something with a better name.
> Otherwise migrate the explicit determine_rate op to this new function
> and don't set the flag.
> 
> It may be possible to entirely remove the CLK_SET_RATE_NO_REPARENT flag
> with this design, if the determine_rate clk_op can call the inner
> wrapper function instead of __clk_mux_determine_rate*() (those
> underscores are awful, we should just prefix them with clk_hw_mux_*()
> and live happier). That should be another patch series.

Sorry but it's not really clear to me what you expect in the v2 of this
series (if you even expect one). It looks that you don't like the
assignment-if-missing idea Mark suggested, but should I just
rebase/resend or did you expect something else?

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists