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

[Florian Fainelli <florian.fainelli@broadcom.com>]

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