LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Alex Bee <knaerzche@gmail.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, "Heiko Stübner" <heiko@sntech.de>,
	linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v1 1/6] clk: divider: Implement and wire up .determine_rate by default
Date: Fri, 15 Oct 2021 14:31:59 -0700	[thread overview]
Message-ID: <163433351924.1688384.17959086273596597053@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <67995168-e0fc-0916-7c34-3efedf4bad00@gmail.com>

Quoting Alex Bee (2021-10-15 12:14:36)
> 
> Am 14.10.21 um 23:34 schrieb Martin Blumenstingl:
> > On Thu, Oct 14, 2021 at 2:11 PM Martin Blumenstingl
> > <martin.blumenstingl@googlemail.com> wrote:
> > [...]
> >>> Reverting this commit makes it work again: Unless there is a quick and
> >>> obvious fix for that, I guess this should be done for 5.15 - even if the
> >>> real issue is somewhere else.
> >> Reverting this patch is fine from the Amlogic SoC point of view.
> >> The main goal was to clean up / improve the CCF code.
> >> Nothing (that I am aware of) is going to break in Amlogic land if we
> >> revert this.
> > Unfortunately only now I realized that reverting this patch would also
> > require reverting the other five patches in this series (since they
> > depend on this one).
> Indeed, that whole series would need have to reverted, which is clear 
> (to me) when looking at the patches.
> > For this reason I propose changing the order of the checks in
> > clk-composite.c - see the attached patch (which I can send as a proper
> > one once agreed that this is the way to go forward)
> 
> Yes, your patch papers over the actual issue (no best parent-selection 
> in case determine_rate is used) and fixes it for now - as expected.
> 
> But it is not a long-term solution, as we will be at the same point, as 
> soon as round_rate gets removed from clk-divider. For me, who is 
> semi-knowledged in clock-framework, it was relatively hard to figure out 
> what was going on. "I'll do this later" has often been heard here.
> 
> Though, I don't fully follow why moving the priority of determine_rate 
> lower would have been necessary anyways: from what I understand 
> determine_rate is expected to be the future-replacement of round_rate 
> everywhere and should be preferred.

This is the only place I can see where we would have to keep round_rate
around, to mesh together rate rounding with parent selection. We can
probably stop using round_rate in the framework and only use it in the
composite code. It's not a big deal but it's sort of annoying that we
won't be able to fully remove round_rate from the clk_ops without
resolving this. Long term it may make sense to get rid of the composite
clk code entirely. It's pretty confusing code to read and encourages use
of the "basic clk types" which I'd like to see be used via direct
function calls instead of through clk_ops structures.

  reply	other threads:[~2021-10-15 21:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02 22:51 [PATCH v1 0/6] clk: switch dividers to .determine_rate Martin Blumenstingl
2021-07-02 22:51 ` [PATCH v1 1/6] clk: divider: Implement and wire up .determine_rate by default Martin Blumenstingl
2021-08-06  1:10   ` Stephen Boyd
2021-10-14  9:55   ` Alex Bee
2021-10-14 12:11     ` Martin Blumenstingl
2021-10-14 21:34       ` Martin Blumenstingl
2021-10-14 22:52         ` Stephen Boyd
2021-10-15 12:05           ` [PATCH] clk: composite: Also consider .determine_rate for rate + mux composites Martin Blumenstingl
2021-10-15 21:27             ` Stephen Boyd
2021-11-01 20:19             ` Guillaume Tucker
2021-11-01 20:58               ` Martin Blumenstingl
2021-11-01 21:59                 ` Robin Murphy
2021-11-01 22:11                   ` Robin Murphy
2021-11-01 22:41                     ` Alex Bee
2021-11-02  7:58                       ` Guillaume Tucker
2021-11-02 21:40                         ` LABBE Corentin
2021-10-15 19:14         ` [PATCH v1 1/6] clk: divider: Implement and wire up .determine_rate by default Alex Bee
2021-10-15 21:31           ` Stephen Boyd [this message]
2021-07-02 22:51 ` [PATCH v1 2/6] clk: imx: clk-divider-gate: Switch to clk_divider.determine_rate Martin Blumenstingl
2021-07-19 10:43   ` Abel Vesa
2021-07-29 11:30   ` Abel Vesa
2021-07-02 22:51 ` [PATCH v1 3/6] clk: bcm2835: " Martin Blumenstingl
2021-07-05  6:57   ` Marek Szyprowski
2021-08-06  1:10   ` Stephen Boyd
2021-07-02 22:51 ` [PATCH v1 4/6] clk: stm32f4: " Martin Blumenstingl
2021-08-06  1:10   ` Stephen Boyd
2021-07-02 22:51 ` [PATCH v1 5/6] clk: stm32h7: " Martin Blumenstingl
2021-08-06  1:10   ` Stephen Boyd
2021-07-02 22:51 ` [PATCH v1 6/6] clk: stm32mp1: " Martin Blumenstingl
2021-08-06  1:10   ` Stephen Boyd
2021-08-03 19:32 ` [PATCH v1 0/6] clk: switch dividers to .determine_rate Martin Blumenstingl
2021-08-03 20:16   ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=163433351924.1688384.17959086273596597053@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=heiko@sntech.de \
    --cc=knaerzche@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=martin.blumenstingl@googlemail.com \
    --subject='Re: [PATCH v1 1/6] clk: divider: Implement and wire up .determine_rate by default' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).