From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Alper Nebi Yasak <alpernebiyasak@gmail.com>,
linux-kernel@vger.kernel.org
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Stephen Boyd" <sboyd@kernel.org>,
linux-clk@vger.kernel.org, "Chen-Yu Tsai" <wenst@chromium.org>,
linux-arm-kernel@lists.infradead.org,
"Michael Turquette" <mturquette@baylibre.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] clock: mediatek: mt8173: Handle unallocated infracfg clock data
Date: Thu, 9 Nov 2023 10:05:16 +0100 [thread overview]
Message-ID: <3b6c474f-669d-4c6e-8d56-ea65958a3b48@collabora.com> (raw)
In-Reply-To: <20231108213734.140707-1-alpernebiyasak@gmail.com>
Il 08/11/23 22:33, Alper Nebi Yasak ha scritto:
> The MT8173 infracfg clock driver does initialization in two steps, via a
> CLK_OF_DECLARE_DRIVER declaration. However its early init function
> doesn't get to run when it's built as a module, presumably since it's
> not loaded by the time it would have been called by of_clk_init(). This
> causes its second-step probe() to return -ENOMEM when trying to register
> clocks, as the necessary clock_data struct isn't initialized by the
> first step.
>
> MT2701 and MT6797 clock drivers also use this mechanism, but they try to
> allocate the necessary clock_data structure if missing in the second
> step. Mimic that for the MT8173 infracfg clock as well to make it work
> as a module.
>
> Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
> ---
> I've tried adding cpumux support to clk-mtk.c then switching this over
> to simple probe functions and it appears to work for me, though I don't
> know clock systems enough to recognize if it's subtly broken instead.
> That'd remove this piece of code, but this might still be worth applying
> to backport to stable kernels.
>
> If I'm reading things correctly, it looks like it would be possible to
> add cpumux & pll & pllfh support to clk-mtk.c, then move most if not
> every driver to simple probe, with one file per clock and module
> support. How much of that is desirable? In what order do the parts need
> to be registered?
>
Thing is, if (!infra_clk_data) at infracfg_probe time, then INFRA_CLK_13M==-ENOENT!
If you do this, you should at least also send a devicetree commit that adds
clk13m: fixed-factor-clock-13m {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clocks = <&clk26m>;
clock-div = <2>;
clock-mult = <1>;
clock-output-names = "clk13m";
};
....otherwise this solution is incomplete! ;-)
Regarding the CPUMUX support, when I've restructured the MediaTek clocks, I've also
been thinking about doing this, but decided not to do it because that'd be a check
done on ~10 clock drivers per SoC, of which only one is expected to succeed... I
see that as a waste of cycles at boot...
...but if anyone thinks otherwise, I'm fine with it...
Anyway.
Can you please fix the commit title to be consistent with the others and send a v2?
In this case, that would be
"clk: mediatek: mt8173-infracfg: Handle unallocated infracfg when module"
P.S.: Good job!
Cheers,
Angelo
> drivers/clk/mediatek/clk-mt8173-infracfg.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173-infracfg.c b/drivers/clk/mediatek/clk-mt8173-infracfg.c
> index 2f2f074e231a..ecc8b0063ea5 100644
> --- a/drivers/clk/mediatek/clk-mt8173-infracfg.c
> +++ b/drivers/clk/mediatek/clk-mt8173-infracfg.c
> @@ -98,7 +98,17 @@ CLK_OF_DECLARE_DRIVER(mtk_infrasys, "mediatek,mt8173-infracfg",
> static int clk_mt8173_infracfg_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> - int r;
> + int r, i;
> +
> + if (!infra_clk_data) {
> + infra_clk_data = mtk_alloc_clk_data(CLK_INFRA_NR_CLK);
> + if (!infra_clk_data)
> + return -ENOMEM;
> + } else {
> + for (i = 0; i < CLK_INFRA_NR_CLK; i++)
> + if (infra_clk_data->hws[i] == ERR_PTR(-EPROBE_DEFER))
> + infra_clk_data->hws[i] = ERR_PTR(-ENOENT);
> + }
>
> r = mtk_clk_register_gates(&pdev->dev, node, infra_gates,
> ARRAY_SIZE(infra_gates), infra_clk_data);
>
> base-commit: 2220f68f4504aa1ccce0fac721ccdb301e9da32f
next prev parent reply other threads:[~2023-11-09 9:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 21:33 [PATCH] clock: mediatek: mt8173: Handle unallocated infracfg clock data Alper Nebi Yasak
2023-11-09 9:05 ` AngeloGioacchino Del Regno [this message]
2023-11-15 17:34 ` Alper Nebi Yasak
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=3b6c474f-669d-4c6e-8d56-ea65958a3b48@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=alpernebiyasak@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
--cc=wenst@chromium.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