LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Alex Bee <knaerzche@gmail.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: Thu, 14 Oct 2021 14:11:37 +0200	[thread overview]
Message-ID: <CAFBinCAVtd8gmcuvGU79-85CqhSU8a3mBCa_jweeZBd59u+amQ@mail.gmail.com> (raw)
In-Reply-To: <4eb964ac-4fff-b59d-2660-2f84d8af5901@gmail.com>

Hi Alex,

On Thu, Oct 14, 2021 at 11:55 AM Alex Bee <knaerzche@gmail.com> wrote:
[...]
> This breaks lot of clocks for Rockchip which intensively uses
> composites,  i.e. those clocks will always stay at the initial parent,
> which in some cases  is the XTAL clock and I strongly guess it is the
> same for other platforms,  which use composite clocks having more than
> one parent (e.g. mediatek, ti ...)
Sorry for that and thanks for bisecting this!

> Example (RK3399)
> clk_sdio is set (initialized) with XTAL (24 MHz) as parent in u-boot.
> It will always stay at this parent, even if the mmc driver sets a rate
> of  200 MHz (fails, as the nature of things), which should switch it to
> any of its possible parent PLLs defined in
> mux_pll_src_cpll_gpll_npll_ppll_upll_24m_p (see clk-rk3399.c)  - which
> never happens.
My question to Stephen et. al. is: where is the correct place to solve this?
What I came up with so far (in no particular order):
1) not using clk-composite from clock drivers and letting CCF take
care of re-parenting clocks as needed (and as specified with
CLK_SET_RATE_NO_REPARENT)
2) clk-composite.c: extending the logic so "rate" clocks with
.determine_rate include the existing logic which only applies to
.round_rate (which means clk-composite.c is then responsible for
finding the best possible parent clock)
3) clk-divider.c: extending the logic here to account for clk_hws with
multiple parents

For 3) I am wondering whether this would even work because it seems
that clk-composite uses multiple struct clk_hw.
Letting the divider handle multiple parents means it would need to
know about the information which is only available in mux_hw - whereas
clk-composite currently passes rate_hw (struct clk_hw for the
divider).

I am happy to work on a patch for this if I can get some help with
testing (since I don't have any board with Rockchip SoC).

> 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.



Best regards,
Martin

  reply	other threads:[~2021-10-14 12:11 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 [this message]
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
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=CAFBinCAVtd8gmcuvGU79-85CqhSU8a3mBCa_jweeZBd59u+amQ@mail.gmail.com \
    --to=martin.blumenstingl@googlemail.com \
    --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=sboyd@kernel.org \
    --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).