Hi,

a small series to review how the SCMI Clock driver chooses and sets up the
CLK operations to associate to a clock when registering with CLK framework.

SCMI clocks exposed by the platform sports a growing number of clock
properties since SCMI v3.2: discovered SCMI clocks could be restricted in
terms of capability to set state/rate/parent/duty_cycle and the platform
itself can have a varying support in terms of atomic support.

Knowing upfront which operations are NOT allowed on some clocks helps
avoiding needless message exchanges.

As a result, the SCMI Clock driver, when registering resources with the
CLK framework, aims to provide only the specific clk_ops as known to be
certainly supported by the specific SCMI clock resource.

Using static pre-compiled clk_ops structures to fulfill all the possible
(and possibly growing) combinations of clock features is cumbersome and
error-prone (there are 32 possible combinations as of now to account for
the above mentioned clock features variation).

This rework introduces a dynamic allocation mechanism to be able to
configure the required clk_ops at run-time when the SCMI clocks are
enumerated.

Only one single clk_ops is generated (per driver instance) for each of the
features combinations effectively found in the set of returned SCMI
resources.

Once this preliminary rework is done in 1/5, the following patches use this
new clk_ops schema to introduce a number of restricted clk_ops depending on
the specific retrieved SCMI clocks characteristics.

Based on v6.9-rc1

Thanks,
Cristian

v2 -> v3
- moving scmi_clk_ops_db from being global to a per-instance/per-probe
  structure to avoid sharing devm_ allocated clk_ops between different
  driver instances.
- using bits.h macros
- fixed a few dox comments
- explicit unit in atomic_threshold_us
- added a runtime size-check before accessing scmi_clk_ops_db using feats_key
- reworked scmi_clk_ops_alloc call to reduce nesting
- using transport_is_atomic instead of is_atomic to be clearer
- using SCMI_<feats>_SUPPORTED instead of SCMI<feats>_FORBIDDEN

v1 -> V2
- rebased on v6.9-rc1

Cristian Marussi (5):
  clk: scmi: Allocate CLK operations dynamically
  clk: scmi: Add support for state control restricted clocks
  clk: scmi: Add support for rate change restricted clocks
  clk: scmi: Add support for re-parenting restricted clocks
  clk: scmi: Add support for get/set duty_cycle operations

 drivers/clk/clk-scmi.c | 249 +++++++++++++++++++++++++++++++++--------
 1 file changed, 201 insertions(+), 48 deletions(-)

-- 
2.44.0

Quoting Cristian Marussi (2024-04-15 09:36:44)
> Hi,
> 
> a small series to review how the SCMI Clock driver chooses and sets up the
> CLK operations to associate to a clock when registering with CLK framework.

Did you want me to merge this through clk tree?

On Fri, Apr 19, 2024 at 07:08:54PM -0700, Stephen Boyd wrote:
> Quoting Cristian Marussi (2024-04-15 09:36:44)
> > Hi,
> > 
> > a small series to review how the SCMI Clock driver chooses and sets up the
> > CLK operations to associate to a clock when registering with CLK framework.
> 
> Did you want me to merge this through clk tree?

I am fine either way. You add:

Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>

if you prefer to take it. Or else please provide your ack for me to
take it via SCMI tree.

-- 
Regards,
Sudeep

Quoting Sudeep Holla (2024-04-22 01:06:06)
> On Fri, Apr 19, 2024 at 07:08:54PM -0700, Stephen Boyd wrote:
> > Quoting Cristian Marussi (2024-04-15 09:36:44)
> > > Hi,
> > > 
> > > a small series to review how the SCMI Clock driver chooses and sets up the
> > > CLK operations to associate to a clock when registering with CLK framework.
> > 
> > Did you want me to merge this through clk tree?
> 
> I am fine either way. You add:
> 
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> 
> if you prefer to take it. Or else please provide your ack for me to
> take it via SCMI tree.
> 

Ok I can take it then.

On Fri, Apr 19, 2024 at 07:08:54PM -0700, Stephen Boyd wrote:
> Quoting Cristian Marussi (2024-04-15 09:36:44)
> > Hi,
> > 
> > a small series to review how the SCMI Clock driver chooses and sets up the
> > CLK operations to associate to a clock when registering with CLK framework.
> 
> Did you want me to merge this through clk tree?

Up to @Sudeep really...

Thanks for the reviewing this series.
Cristian