Re: [PATCH 00/11] SCMI Clock rates discovery rework
From: Cristian Marussi
Date: Tue Mar 03 2026 - 08:12:13 EST
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@xxxxxxx> 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@xxxxxxxxx>
>
Thanks for testing in the real world !
Cristian