Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Message-ID: <04fe725d-c6c9-4db7-9ebe-ce6ea3511844@gmail.com>
Date:   Wed, 15 Nov 2023 20:34:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] clock: mediatek: mt8173: Handle unallocated infracfg
 clock data
Content-Language: en-US, tr, en-GB
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>
Cc:     =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= <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, linux-kernel@vger.kernel.org
References: <20231108213734.140707-1-alpernebiyasak@gmail.com>
 <3b6c474f-669d-4c6e-8d56-ea65958a3b48@collabora.com>
From:   Alper Nebi Yasak <alpernebiyasak@gmail.com>
In-Reply-To: <3b6c474f-669d-4c6e-8d56-ea65958a3b48@collabora.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

Sorry with the late reply. I am trying to get things enabled in Debian
for MT8173 and MT8183 Chromebooks, and needed to post this so I can
refer to this there [1]. Then I worked on things related to that, hence
the delay. Replying here mostly because I wanted to tell you as you
might be interested -- although I do have some module probe ordering
problems that could use some insight...

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/906

On 2023-11-09 12:05 +03:00, AngeloGioacchino Del Regno wrote:
> 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! ;-)

I'm seeing similar blocks added for other SoCs and tried to match what
they did, hoping it's correct for MT8173 as well.

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

Thanks for making it possible to use them as modules, I appreciate it!
It does look like a maintainability vs performance trade off, and I
don't know enough about performance profiling to say it doesn't matter here.

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

Heh, I'm having trouble with titles recently. Sent a v2 just now, with a
second patch for device-tree.

> 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