Re: [PATCH v3 00/15] SCMI Clock rates discovery rework

Florian Fainelli
2026-04-29T15:40:06Z

On 4/28/2026 1:15 PM, Cristian Marussi wrote:
> Hi,
>
> 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 2-6.
>
> A further bigger optimization suggested in a past series [2] by Etienne
> 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
> functionalities already provided by SCMI iterators, though.
>
> Patch 7-14 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 only 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 15 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.
>
> Most notably in this V3 I had:
>
> - picked up Geert fixes on V2: these could have been squashed in the
> original series while maintaining proper Geert's authorship but as of
> now I have simply picked them up and changed their order to be near the
> commit they fix
>
> - dropped the "Harden Clock protocol initialization" patch that caused a
> number of out-of-spec vendor FW to break
>
> Based on v7.1-rc1.
> Tested on ARM/JUNO, RADXA/ROCK5B and an emulated environment.

Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian