From: Alex Bee <knaerzche@gmail.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: linux-clk@vger.kernel.org, sboyd@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 21:14:36 +0200 [thread overview]
Message-ID: <67995168-e0fc-0916-7c34-3efedf4bad00@gmail.com> (raw)
In-Reply-To: <CAFBinCAT-FxcHpt=NCt4g-OfzEUhvxh8TNRcY2hb5kdxna0Uyw@mail.gmail.com>
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.
I guess it's up to the maintainers on how to proceed.
Alex
> Off-list Alex also suggested that I should use rate_ops.determine_rate
> if available.
> While I agree that this makes sense in general my plan is to do this
> in a follow-up patch.
> Changing the order of the conditions is needed anyways and it *should*
> fix the issue reported here (but I have no way of testing that
> unfortunately).
>
> Alex, it would be great if you (or someone with Rockchip boards) could
> test the attached patch and let me know if it fixes the reported
> problem.
>
>
> Best regards,
> Martin
next prev parent reply other threads:[~2021-10-15 19:14 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 ` Alex Bee [this message]
2021-10-15 21:31 ` [PATCH v1 1/6] clk: divider: Implement and wire up .determine_rate by default Stephen Boyd
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=67995168-e0fc-0916-7c34-3efedf4bad00@gmail.com \
--to=knaerzche@gmail.com \
--cc=heiko@sntech.de \
--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 \
--cc=sboyd@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).