linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
To: Chen-Yu Tsai <wenst@chromium.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Chun-Jie Chen <chun-jie.chen@mediatek.com>,
	Miles Chen <miles.chen@mediatek.com>,
	Rex-BC Chen <rex-bc.chen@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
	linux-clk@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/7] clk: mediatek: Move to struct clk_hw provider APIs
Date: Tue, 19 Apr 2022 17:08:16 +0200	[thread overview]
Message-ID: <3591fcc1-d34a-b40a-4e78-edcf9d2ddf08@collabora.com> (raw)
In-Reply-To: <20220419081246.2546159-1-wenst@chromium.org>

Il 19/04/22 10:12, Chen-Yu Tsai ha scritto:
> Hi everyone,
> 
> This is part 2 of my proposed MediaTek clk driver cleanup work [1].
> 

..snip..

> 
> The next phase of the cleanup/improvement shall be to introduce some
> variant of `struct clk_parent_data` to describe clk relationships
> efficiently.
> 
> Please have a look.
> 

Hello Chen-Yu,

I am grateful to see this series, as the MediaTek clock drivers are getting
a bit old, despite new platforms being implemented practically as we speak.

With this, you surely get that I completely agree with the proposed cleanup
and modernization of the entire MediaTek clocks infrastructure, but I think
that introducing a `struct clk_parent_data` for these drivers is, at this
point, a must, that not only fully justifies these patches, but also "makes
the point" - as the effect of that would be a performance improvement as we
would *at least* avoid lots of clk_cpy_name() in case of parent_hws, or in
case or parent_data where no .fw_name is provided (which would be the case
for most of the clocks).

That said, my advice would be to add that conversion to declaring clocks
with .hw.init.parent_data and/or .hw.init.parent_hws to this series as to
really make it complete.

Of course, if you have concerns about old platforms that you cannot test,
or for which this kind of conversion would require a huge amount of effort,
then I would go for converting as many as possible as a first step and then
leave the others for later.

I would envision MT8183, 8186, 8192, 8195 to be a good amount of first
candidates for this great effort.

Cheers,
Angelo

  parent reply	other threads:[~2022-04-19 15:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19  8:12 [RFC PATCH 0/7] clk: mediatek: Move to struct clk_hw provider APIs Chen-Yu Tsai
2022-04-19  8:12 ` [RFC PATCH 1/7] clk: mediatek: Make mtk_clk_register_composite() static Chen-Yu Tsai
2022-04-19 14:45   ` AngeloGioacchino Del Regno
2022-04-19  8:12 ` [RFC PATCH 2/7] clk: mediatek: apmixed: Drop error message from clk_register() failure Chen-Yu Tsai
2022-04-19  8:12 ` [RFC PATCH 3/7] clk: mediatek: Convert mtk_{alloc,free}_clk_data to struct clk_hw Chen-Yu Tsai
2022-04-19  8:12 ` [RFC PATCH 4/7] clk: mediatek: Replace 'struct clk' with 'struct clk_hw' Chen-Yu Tsai
2022-04-19  8:12 ` [RFC PATCH 5/7] clk: mediatek: Switch to clk_hw provider APIs Chen-Yu Tsai
2022-04-19  8:12 ` [RFC PATCH 6/7] clk: mediatek: mt8173: Fix usage of mtk_clk_register_ref2usb_tx() Chen-Yu Tsai
2022-04-19  8:12 ` [RFC PATCH 7/7] clk: mediatek: mt8173: Switch to clk_hw provider APIs Chen-Yu Tsai
2022-04-19 15:08 ` AngeloGioacchino Del Regno [this message]
2022-04-19 16:09   ` [RFC PATCH 0/7] clk: mediatek: Move to struct " Chen-Yu Tsai
2022-04-20 12:02     ` AngeloGioacchino Del Regno
2022-04-21  6:05       ` Chen-Yu Tsai
2022-04-21  9:42         ` AngeloGioacchino Del Regno
2022-04-22  1:40         ` Stephen Boyd
2022-04-22  4:14           ` Chen-Yu Tsai
2022-05-03 16:28 ` Chen-Yu Tsai

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=3591fcc1-d34a-b40a-4e78-edcf9d2ddf08@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=chun-jie.chen@mediatek.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=miles.chen@mediatek.com \
    --cc=mturquette@baylibre.com \
    --cc=rex-bc.chen@mediatek.com \
    --cc=sboyd@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).