From: Cristian Marussi <cristian.marussi@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
sudeep.holla@arm.com, philip.radford@arm.com,
james.quinlan@broadcom.com, f.fainelli@gmail.com,
vincent.guittot@linaro.org, etienne.carriere@foss.st.com,
peng.fan@oss.nxp.com, michal.simek@amd.com,
dan.carpenter@linaro.org, kuninori.morimoto.gx@renesas.com,
marek.vasut+renesas@gmail.com
Subject: Re: [PATCH 00/11] SCMI Clock rates discovery rework
Date: Tue, 3 Mar 2026 13:08:46 +0000 [thread overview]
Message-ID: <aabdXvaSlu1EDgG4@pluto> (raw)
In-Reply-To: <CAMuHMdW9dtAnT2E103kp1zK=LJrER7k1ib8_WPk5aorPRw80uQ@mail.gmail.com>
On Mon, Mar 02, 2026 at 02:25:00PM +0100, Geert Uytterhoeven wrote:
> Hi Cristian,
>
> Thanks for your series!
>
> On Fri, 27 Feb 2026 at 16:33, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > it was a known limitation, in the SCMI Clock protocol support, the lack of
> > dynamic allocation around per-clock rates discovery: fixed size statically
> > per-clock rates arrays did not scale and was increasingly a waste of memory
> > (see [1]).
> >
> > This series aim at solving this in successive steps:
> >
> > - simplify and reduce to the minimum possible the rates data info exposed
> > to the SCMI driver by scmi_clock_info
> > - move away from static fixed allocation of per-clock rates arrays in
> > favour of a completely dynamic runtime allocation: just allocate what
> > is needed based on the effectively discovered
> >
> > This is done in patches 1-6.
> >
> > A further bigger optimization suggested in a past series [1] by Etienne
>
> s/[1]/[2]/
>
> > would be, whenever allowed by the spec, to limit upfront the number of
> > queries in order to simply retrieve min and max rate, that are indeed the
> > only rates needed by the CLK SCMI driver.
> >
> > The approach proposed in [1] was open coding and duplicating some of the
>
> What does [1] refer to?
I messed up the refs..of course...it was just a reference to your thread
where the number of rates where staticallty raised to 64.
>
> > functionalities already provided by SCMI iterators, though.
> >
> > Patch 7-10 implement such optimization instead by:
> >
> > - reworking core SCMI iterators to support bound enumerations
> > - use such new bound iterators to perform the minimum number of queries
> > in order to ony retrieve min an max rate
> >
> > As a final result now the rates enumeration triggered by the CLK SCMI
> > driver, while still allocating for all the existent rates, miminize the
> > number of SCMI CLK_DESCRIBE_RATE messages needed to obtain min and max.
> >
> > Finally, patch 11 introduces a new clock protocol operation to be able to
> > trigger anytime on demand a full enumeration and obtain the full list of
> > rates when needed, not only min/max: this latter method is really only used
> > currently by some dowstream SCMI Test driver of mine.
> >
> > Based on v7.0-rc1.
> >
> > Tested on JUNO and an emulated environment.
>
> Thank you, this removes the need for increasing SCMI_MAX_NUM_RATES on
> R-Car X5H, while decreasing memory usage.
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
Thanks for testing in the real world !
Cristian
prev parent reply other threads:[~2026-03-03 13:08 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 15:32 [PATCH 00/11] SCMI Clock rates discovery rework Cristian Marussi
2026-02-27 15:32 ` [PATCH 01/11] firmware: arm_scmi: Add clock determine_rate operation Cristian Marussi
2026-02-27 16:50 ` Jonathan Cameron
2026-02-28 10:07 ` Cristian Marussi
2026-02-28 0:27 ` Peng Fan
2026-02-28 10:13 ` Cristian Marussi
2026-03-02 12:37 ` Geert Uytterhoeven
2026-03-03 12:46 ` Cristian Marussi
2026-02-27 15:32 ` [PATCH 02/11] clk: scmi: Use new determine_rate clock operation Cristian Marussi
2026-02-28 0:56 ` Peng Fan
2026-02-28 10:23 ` Cristian Marussi
2026-03-02 17:11 ` Brian Masney
2026-03-03 2:54 ` Peng Fan
2026-03-03 12:47 ` Cristian Marussi
2026-03-02 12:39 ` Geert Uytterhoeven
2026-03-03 12:49 ` Cristian Marussi
2026-02-27 15:32 ` [PATCH 03/11] firmware: arm_scmi: Simplify clock rates exposed interface Cristian Marussi
2026-02-28 2:07 ` Peng Fan
2026-02-28 10:34 ` Cristian Marussi
2026-03-02 12:48 ` Geert Uytterhoeven
2026-03-02 13:09 ` Geert Uytterhoeven
2026-03-03 12:42 ` Cristian Marussi
2026-03-03 12:40 ` Cristian Marussi
2026-02-27 15:32 ` [PATCH 04/11] clk: scmi: Use new simplified per-clock rate properties Cristian Marussi
2026-02-28 2:12 ` Peng Fan
2026-02-27 15:32 ` [PATCH 05/11] firmware: arm_scmi: Drop unused clock rate interfaces Cristian Marussi
2026-02-28 2:13 ` Peng Fan
2026-02-27 15:32 ` [PATCH 06/11] firmware: arm_scmi: Make clock rates allocation dynamic Cristian Marussi
2026-02-28 2:29 ` Peng Fan
2026-02-28 10:36 ` Cristian Marussi
2026-02-27 15:32 ` [PATCH 07/11] firmware: arm_scmi: Harden clock parents discovery Cristian Marussi
2026-02-28 2:39 ` Peng Fan
2026-02-28 10:37 ` Cristian Marussi
2026-02-27 15:32 ` [PATCH 08/11] firmware: arm_scmi: Refactor iterators internal allocation Cristian Marussi
2026-02-27 15:32 ` [PATCH 09/11] firmware: arm_scmi: Add bound iterators support Cristian Marussi
2026-02-28 2:44 ` Peng Fan
2026-02-28 2:43 ` Peng Fan (OSS)
2026-02-28 10:42 ` Cristian Marussi
2026-02-27 15:32 ` [PATCH 10/11] firmware: arm_scmi: Use bound iterators to minimize discovered rates Cristian Marussi
2026-02-27 16:53 ` Jonathan Cameron
2026-02-28 10:43 ` Cristian Marussi
2026-02-27 15:32 ` [PATCH 11/11] firmware: arm_scmi: Introduce all_rates_get clock operation Cristian Marussi
2026-02-28 2:49 ` Peng Fan
2026-02-28 10:47 ` Cristian Marussi
2026-03-02 7:18 ` Peng Fan
2026-03-02 10:47 ` Cristian Marussi
2026-03-02 13:25 ` [PATCH 00/11] SCMI Clock rates discovery rework Geert Uytterhoeven
2026-03-03 13:08 ` Cristian Marussi [this message]
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=aabdXvaSlu1EDgG4@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=etienne.carriere@foss.st.com \
--cc=f.fainelli@gmail.com \
--cc=geert@linux-m68k.org \
--cc=james.quinlan@broadcom.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=marek.vasut+renesas@gmail.com \
--cc=michal.simek@amd.com \
--cc=peng.fan@oss.nxp.com \
--cc=philip.radford@arm.com \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.