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 2/5] clk: scmi: Add support for state control restricted clocks
Date: Mon, 15 Apr 2024 17:36:46 +0100 [thread overview]
Message-ID: <20240415163649.895268-3-cristian.marussi@arm.com> (raw)
In-Reply-To: <20240415163649.895268-1-cristian.marussi@arm.com>
Some exposed SCMI Clocks could be marked as non-supporting state changes.
Configure a clk_ops descriptor which does not provide the state change
callbacks for such clocks when registering with CLK framework.
CC: Michael Turquette <mturquette@baylibre.com>
CC: Stephen Boyd <sboyd@kernel.org>
CC: linux-clk@vger.kernel.org
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v2 -> v3
- using SCMI_CLK_STATE_CTRL_SUPPORTED instead of _FORBIDDEN
---
drivers/clk/clk-scmi.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
index 4b6c43d7f5f3..e70708573965 100644
--- a/drivers/clk/clk-scmi.c
+++ b/drivers/clk/clk-scmi.c
@@ -19,6 +19,7 @@
enum scmi_clk_feats {
SCMI_CLK_ATOMIC_SUPPORTED,
+ SCMI_CLK_STATE_CTRL_SUPPORTED,
SCMI_CLK_FEATS_COUNT
};
@@ -230,15 +231,19 @@ scmi_clk_ops_alloc(struct device *dev, unsigned long feats_key)
* only the prepare/unprepare API, as allowed by the clock framework
* when atomic calls are not available.
*/
- if (feats_key & BIT(SCMI_CLK_ATOMIC_SUPPORTED)) {
- ops->enable = scmi_clk_atomic_enable;
- ops->disable = scmi_clk_atomic_disable;
- ops->is_enabled = scmi_clk_atomic_is_enabled;
- } else {
- ops->prepare = scmi_clk_enable;
- ops->unprepare = scmi_clk_disable;
+ if (feats_key & BIT(SCMI_CLK_STATE_CTRL_SUPPORTED)) {
+ if (feats_key & BIT(SCMI_CLK_ATOMIC_SUPPORTED)) {
+ ops->enable = scmi_clk_atomic_enable;
+ ops->disable = scmi_clk_atomic_disable;
+ } else {
+ ops->prepare = scmi_clk_enable;
+ ops->unprepare = scmi_clk_disable;
+ }
}
+ if (feats_key & BIT(SCMI_CLK_ATOMIC_SUPPORTED))
+ ops->is_enabled = scmi_clk_atomic_is_enabled;
+
/* Rate ops */
ops->recalc_rate = scmi_clk_recalc_rate;
ops->round_rate = scmi_clk_round_rate;
@@ -294,6 +299,9 @@ scmi_clk_ops_select(struct scmi_clk *sclk, bool atomic_capable,
if (atomic_capable && ci->enable_latency <= atomic_threshold_us)
feats_key |= BIT(SCMI_CLK_ATOMIC_SUPPORTED);
+ if (!ci->state_ctrl_forbidden)
+ feats_key |= BIT(SCMI_CLK_STATE_CTRL_SUPPORTED);
+
if (WARN_ON(feats_key >= db_size))
return NULL;
--
2.44.0
next prev parent 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 [PATCH v3 0/5] Rework SCMI Clock driver clk_ops setup procedure Cristian Marussi
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 ` Cristian Marussi [this message]
2024-04-22 19:04 ` [PATCH v3 2/5] clk: scmi: Add support for state control restricted clocks 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-3-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).