From: Cristian Marussi <cristian.marussi@arm.com>
To: Peng Fan <peng.fan@nxp.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
Cristian Marussi <cristian.marussi@arm.com>,
Sebin Francis <sebin.francis@ti.com>,
Stephen Boyd <sboyd@kernel.org>,
"arm-scmi@vger.kernel.org" <arm-scmi@vger.kernel.org>
Subject: Re: Add OEM extension for clk-scmi
Date: Mon, 6 Oct 2025 16:34:29 +0100 [thread overview]
Message-ID: <aOPhhYmWtXHBjYAO@pluto> (raw)
In-Reply-To: <PAXPR04MB8459F97453698D981B52BF38881AA@PAXPR04MB8459.eurprd04.prod.outlook.com>
On Tue, Sep 30, 2025 at 01:22:15PM +0000, Peng Fan wrote:
> Hi All,
>
Hi,
> This is to discuss the spread spectrum support for clk-scmi. I think
> it is hard to provide a generic framework from scmi core level.
> Because oem extension varies per protocol. And most of the
> code added is in consumer driver side saying clk-scmi.c not
> the firmware/arm_scmi/clock.c.
>
> Based on above, I am thinking to follow what arm-smmu
> implements(arm_smmu_impl_init), by calling a function
> scmi_clk_oem_init in probe.
>
> And define a generic feature macro in enum scmi_clk_feats:
> SCMI_CLK_EXT_OEM_SSC_SUPPORTED,
>
> Also define a new structure for OEM stuff:
> +struct scmi_clk_plat {
> + int (*query_oem_feats)(const struct scmi_protocol_handle *ph,
> + u32 id, unsigned long *feats_key);
> + int (*set_spread_spectrum)(struct clk_hw *hw,
> + const struct clk_spread_spectrum *ss_conf);
> +};
> +
>
> Add a new file clk-scmi-oem for up plat hooks implementation.
>
> And add clk-scmi.h to move some code that would be shared
> between clk-scmi.c and clk-scmi-oem.c
>
> This is just an idea, more code pieces as below, this does not
> pass compiling, just an idea in my mind.
>
> If you think this is feasible, I will do a formal patch.
>
> BTW: I will be on holiday in the following week. I will check
> email from time to time, but may not respond in time.
>
> drivers/clk/clk-scmi-oem.c
> static int scmi_clk_imx_set_spread_spectrum(struct clk_hw *hw,
> struct clk_spread_spectrum *ss_conf)
> {
> /* TODO */
> return 0;
> }
>
> static int scmi_clk_imx_query_oem_feats(const struct scmi_protocol_handle *ph,
> u32 id, unsigned long *feats_key)
> {
> /* TODO */
> if ( the clk supports SSC)
> *feats_key |= SCMI_CLK_EXT_OEM_SSC_SUPPORTED;
> return 0;
> }
>
> static const struct scmi_clk_plat scmi_clk_imx_plat = {
> .query_ext_oem_feats = scmi_clk_imx_query_oem_feats,
> .set_spread_spectrum = scmi_clk_imx_set_spread_spectrum,
> };
>
> int scmi_clk_oem_init(struct scmi_device *dev, struct scmi_clk_plat *data)
> {
> if (!strcmp(handle->version->vendor_id, SCMI_IMX_VENDOR) &&
> !strcmp(handle->version->sub_vendor_id, SCMI_IMX_SUBVENDOR)) {
> *data = scmi_clk_imx_plat;
> } else {
> /* Other SoC vendors (TI) */
> }
>
> return 0;
> }
>
> In clk-scmi.c, using the hook to update oem feats
> @@ -375,6 +388,9 @@ scmi_clk_ops_select(struct scmi_clk *sclk, bool atomic_capable,
> &val, NULL, false);
> if (!ret)
> feats_key |= BIT(SCMI_CLK_DUTY_CYCLE_SUPPORTED);
> +
> + if (data->query_ext_oem_feats)
> + data->query_ext_oem_feats(sclk->ph, sclk->id, &feats_key);
> }
>
> @@ -313,11 +322,15 @@ scmi_clk_ops_alloc(struct device *dev, unsigned long feats_key)
> ops->set_duty_cycle = scmi_clk_set_duty_cycle;
> }
>
> + if (feats_key & BIT(SCMI_CLK_EXT_OEM_SSC_SUPPORTED))
> + ops->set_spread_spectrum = data->set_spread_spectrum;
> +
> return ops;
> }
In general seems a sensible approach...once you had a full series we can
reason about it better probably....and see how much more (or less) we
can/should generalize.
Thanks for this,
Cristian
next prev parent reply other threads:[~2025-10-06 15:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-30 13:22 Add OEM extension for clk-scmi Peng Fan
2025-10-06 10:30 ` Sebin Francis
2025-10-06 15:34 ` Cristian Marussi [this message]
2025-10-08 12:35 ` Peng Fan
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=aOPhhYmWtXHBjYAO@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=sboyd@kernel.org \
--cc=sebin.francis@ti.com \
--cc=sudeep.holla@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.