linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 15 Jan 2025 16:58:55 +0100	[thread overview]
Message-ID: <1j4j205ark.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <697b634770d789ef8ff0e05cec9465f5.sboyd@kernel.org> (Stephen Boyd's message of "Tue, 07 Jan 2025 13:28:50 -0800")

On Tue 07 Jan 2025 at 13:28, Stephen Boyd <sboyd@kernel.org> wrote:

> Quoting Jerome Brunet (2025-01-07 06:46:41)
>> 
>> So, if it's OK, I'll resend this series with a temporary solution to
>> remove tables. Removing the table simplify the other clean-up I have
>> already line-up and avoid some unnecessary diffs. I'll circle back to
>> reworking the init_data afterward.
>> 
>
> Ok, sure. Let's see how it goes.


Hey Stephen,

While implementing a temporary solution I've been thinking about the
longer term one (I'd rather not end up stuck on a temporary one, so it
has been bothering me a bit)

I'll reformulate what I'm trying to acheive.

I'd like to register controller init hook to apply on all the clocks of
a particular type. The reason to do that is to drop the big clk_regmap
table that are a pain to maintain (in addition to be ugly). I hoped it
would also save a bit of memory.

The solutions we've been discussing so far feels like we are moving
around the problem, recreating the memory saved somewhere else,
perhaps in a more complicated way. I'd like to find something more
convinient to use, which does not scale the memory used with the number
of clock registered. The point is not a different hook for clk_hw after
all.

Here is an idea, how about list of hook identified by ops and controller ?

The node would look like this

struct clk_type_init_node {
       struct list_head	        entry;
       
       struct device_node	*of_node;
       struct device		*dev;
       const struct clk_ops	*ops;

       int (*init_hook)(struct clk_hw *hw);
};

The change would be minimal in core CCF, just searching the list for a
match in clk_register. On most platform the list would be empty so there
is virtually no penalty when it is not used.

From the controller, the usage would be very simple, just calling a
function before registering the clocks, something like:

int clk_type_register_dev_hook(struct device *dev,
                               const struct clk_ops *ops,
                               int (*init_hook)(struct clk_hw *hw))

or the 'of_node' equivalent.

I admit this is heavily inspired by how devres works :) but it does solve
the early clock controller problem and does not scale with the number of
clock registered.

Would you be ok with this approach ?

-- 
Jerome


  reply	other threads:[~2025-01-15 16:00 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
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 [this message]
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=1j4j205ark.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;
as well as URLs for NNTP newsgroup(s).