Linux clock framework development
 help / color / mirror / Atom feed
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




  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