Messages in this thread | | | From | Cristian Marussi <> | Subject | [PATCH 0/5] Rework SCMI Clock driver clk_ops setup procedure | Date | Tue, 27 Feb 2024 19:48:07 +0000 |
| |
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 for each of the features combinations effectively found in the set of returned SCMI resources.
Based on sudeep/for-linux-next.
Thanks, Cristian
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 | 226 ++++++++++++++++++++++++++++++++--------- 1 file changed, 179 insertions(+), 47 deletions(-)
-- 2.43.0
| |