Received-SPF: pass (google.com: domain of linux-kernel+bounces-145566-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Cristian Marussi <cristian.marussi@arm.com>
To: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-clk@vger.kernel.org
Cc: sudeep.holla@arm.com,
	james.quinlan@broadcom.com,
	f.fainelli@gmail.com,
	vincent.guittot@linaro.org,
	peng.fan@oss.nxp.com,
	michal.simek@amd.com,
	quic_sibis@quicinc.com,
	quic_nkela@quicinc.com,
	souvik.chakravarty@arm.com,
	mturquette@baylibre.com,
	sboyd@kernel.org,
	Cristian Marussi <cristian.marussi@arm.com>
Subject: [PATCH v3 0/5] Rework SCMI Clock driver clk_ops setup procedure
Date: Mon, 15 Apr 2024 17:36:44 +0100
Message-ID: <20240415163649.895268-1-cristian.marussi@arm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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