From: Jerome Brunet <jbrunet@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Michael Turquette <mturquette@baylibre.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] clk: amlogic: drop clk_regmap tables
Date: Sat, 21 Dec 2024 12:09:28 +0100 [thread overview]
Message-ID: <1ja5cp8f87.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <9f1d69ebe1ddce5dfc170e986c9213f2.sboyd@kernel.org> (Stephen Boyd's message of "Fri, 20 Dec 2024 16:12:03 -0800")
On Fri 20 Dec 2024 at 16:12, Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Jerome Brunet (2024-12-20 09:17:43)
>> Remove the big clk_regmap tables that are used to populate the regmap
>> field of clk_regmap clocks at runtime. Instead of using tables, use devres
>> to allow the clocks to get the necessary regmap.
>>
>> A simpler solution would have been to use dev_get_regmap() but this would
>> not work with syscon based controllers.
>
> Why not have two init functions, one that uses the syscon approach from
> the parent device?
That would duplicate all the ops and would not scale if anything else
comes along. It would also tie the controller quirks with
clock ops. I would like to keep to clock ops and controllers decoupled as
much as possible
> Is the typical path to not use a syscon anyway?
>
I sure hope there will be no new syscon based controller but, ATM, around
50% are syscon based in drivers/clk/meson. Those are here to stay and I
doubt we can do anything about it.
>>
>> This rework save a bit memory and the result is less of a maintenance
>> burden.
>>
>> Unfortunately meson8b is left out for now since it is an early clock
>> driver that does not have proper device support for now.
>
> We should add a clk_hw_get_of_node() function that returns
> hw->core->of_node. Then there can be a similar function that looks at
> the of_node of a clk registered with of_clk_hw_register() and tries to
> find the regmap either with
> syscon_node_to_regmap(clk_hw_get_of_node(hw)) or on the parent of the
> node for the clk.
That's the thing. It means encoding the controller quirk of how to get
regmap in the clock ops. I would be prefer to avoid that.
With what you are suggesting I could make an ops that
* Try dev_get_regmap() first
* Try the syscon/of_node way next
I can make this "trial an error" approach work but I think it is pretty
nasty and encode controller stuff inside the clock driver.
>
> TL;DR: Don't use devres.
Using it makes thing nice and tidy. clk_regmap does not care were regmap
comes from. It just picks it up where it has been prepared
That approach could be extended to support controller with multiple
regmaps, with a name that does not depend on regmap_config and is local
to the clock controller. This will be useful when the name if defined
somewhere else (syscon, auxiliary device, etc ...)
>
>>
>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>> ---
>> drivers/clk/meson/a1-peripherals.c | 165 +-------------
>> drivers/clk/meson/a1-pll.c | 18 +-
>> drivers/clk/meson/axg-aoclk.c | 22 --
>> drivers/clk/meson/axg-audio.c | 435 +------------------------------------
>> drivers/clk/meson/axg.c | 131 -----------
>> drivers/clk/meson/c3-peripherals.c | 212 +-----------------
>> drivers/clk/meson/c3-pll.c | 34 +--
>> drivers/clk/meson/clk-cpu-dyndiv.c | 1 +
>> drivers/clk/meson/clk-dualdiv.c | 2 +
>> drivers/clk/meson/clk-mpll.c | 6 +
>> drivers/clk/meson/clk-phase.c | 11 +
>> drivers/clk/meson/clk-pll.c | 7 +
>> drivers/clk/meson/clk-regmap.c | 88 ++++++++
>> drivers/clk/meson/clk-regmap.h | 7 +
>> drivers/clk/meson/g12a-aoclk.c | 34 ---
>> drivers/clk/meson/g12a.c | 261 ----------------------
>> drivers/clk/meson/gxbb-aoclk.c | 19 --
>> drivers/clk/meson/gxbb.c | 393 ---------------------------------
>> drivers/clk/meson/meson-aoclk.c | 7 +-
>> drivers/clk/meson/meson-aoclk.h | 2 -
>> drivers/clk/meson/meson-eeclk.c | 6 +-
>> drivers/clk/meson/meson-eeclk.h | 2 -
>> drivers/clk/meson/meson8-ddr.c | 11 +-
>> drivers/clk/meson/s4-peripherals.c | 231 +-------------------
>> drivers/clk/meson/s4-pll.c | 33 +--
>> drivers/clk/meson/sclk-div.c | 5 +
>> drivers/clk/meson/vclk.c | 2 +
>> drivers/clk/meson/vid-pll-div.c | 1 +
>> 28 files changed, 165 insertions(+), 1981 deletions(-)
>
> It would be more focused if you split the patch into two. One that
> installs the init clk_op and implements the logic to hook up the regmap
> and one that removes the arrays that are no longer used.
I should have done so indeed.
--
Jerome
next prev parent reply other threads:[~2024-12-21 11:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 17:17 [PATCH 0/3] clk: amlogic: drop clk_regmap tables Jerome Brunet
2024-12-20 17:17 ` [PATCH 1/3] clk: add a clk_hw helper to get the associate device structure Jerome Brunet
2024-12-20 23:55 ` Stephen Boyd
2024-12-20 17:17 ` [PATCH 2/3] clk: amlogic: drop clk_regmap tables Jerome Brunet
2024-12-21 0:12 ` Stephen Boyd
2024-12-21 11:09 ` Jerome Brunet [this message]
2024-12-31 1:08 ` Stephen Boyd
2025-01-06 10:12 ` Jerome Brunet
2025-01-06 21:09 ` Stephen Boyd
2025-01-07 14:46 ` Jerome Brunet
2025-01-07 21:28 ` Stephen Boyd
2025-01-15 15:58 ` Jerome Brunet
2025-02-27 22:55 ` Stephen Boyd
2025-03-21 15:46 ` Jerome Brunet
2025-03-21 15:55 ` Jerome Brunet
2024-12-20 17:17 ` [PATCH 3/3] clk: amlogic: s4: remove unused data Jerome Brunet
2024-12-23 7:59 ` Chuan Liu
2024-12-23 9:01 ` [DMARC error][DKIM error]Re: " Dmitry Rokosov
2024-12-24 5:20 ` Chuan Liu
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=1ja5cp8f87.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--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