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 [thread overview]
Message-ID: <20240415163649.895268-1-cristian.marussi@arm.com> (raw)
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
next reply other threads:[~2024-04-15 16:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 16:36 Cristian Marussi [this message]
2024-04-15 16:36 ` [PATCH v3 1/5] clk: scmi: Allocate CLK operations dynamically Cristian Marussi
2024-04-22 19:04 ` Stephen Boyd
2024-04-15 16:36 ` [PATCH v3 2/5] clk: scmi: Add support for state control restricted clocks Cristian Marussi
2024-04-22 19:04 ` Stephen Boyd
2024-04-15 16:36 ` [PATCH v3 3/5] clk: scmi: Add support for rate change " Cristian Marussi
2024-04-22 19:04 ` Stephen Boyd
2024-04-15 16:36 ` [PATCH v3 4/5] clk: scmi: Add support for re-parenting " Cristian Marussi
2024-04-22 19:04 ` Stephen Boyd
2024-04-15 16:36 ` [PATCH v3 5/5] clk: scmi: Add support for get/set duty_cycle operations Cristian Marussi
2024-04-22 19:03 ` Stephen Boyd
2024-04-20 2:08 ` [PATCH v3 0/5] Rework SCMI Clock driver clk_ops setup procedure Stephen Boyd
2024-04-21 9:31 ` Cristian Marussi
2024-04-22 8:06 ` Sudeep Holla
2024-04-22 19:00 ` Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240415163649.895268-1-cristian.marussi@arm.com \
--to=cristian.marussi@arm.com \
--cc=f.fainelli@gmail.com \
--cc=james.quinlan@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=mturquette@baylibre.com \
--cc=peng.fan@oss.nxp.com \
--cc=quic_nkela@quicinc.com \
--cc=quic_sibis@quicinc.com \
--cc=sboyd@kernel.org \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).