Hi Sudeep,

Subject: Re: [PATCH v4 5/5] clk: scmi: Support Spread Spectrum for
NXP i.MX95

On Wed, Sep 24, 2025 at 11:43:56AM +0000, Peng Fan wrote:

quoted

quoted

Subject: Re: [PATCH v4 5/5] clk: scmi: Support Spread Spectrum for
NXP i.MX95

...

quoted

quoted

quoted

quoted

       SCMI_CLOCK_CFG_OEM_START = 0x80,
+     SCMI_CLOCK_CFG_IMX_SSC = 0x80,

TI is also planning to implement the same in our upcoming

platform.

quoted

quoted

quoted

quoted

so can we use a generic ID instead of vender specfic message ID?

I tried to push to new generic ID [1] in half a year ago, but in
the end ARM decided not to add generic ID for spread spectrum

support.

quoted

quoted

quoted

To i.MX, it is too late to use a generic ID and waiting spec, i.MX
firmware has been public for quite some time and passed several

external releases.

quoted

So I need to use what our firmware adds and spec allows: vendor
extension.

Thanks for the quick response,
Since this implementation is specific to i.MX, can you move this to
a vendor specific file, so that it will not break i.MX's firmware
and TI can implement SSC in TI specific file.

i.MX has encountered issue with pinctrl-scmi.c and pinctrl-imx-scmi.c
both supports SCMI PINCTRL. Current linux scmi does not support

both

quoted

drivers built in kernel image, because scmi devlink issue.

Sudeep said he would address the devlink issue in 6.19 cycle.

Yes it is a different issue IMO and nothing related to this.

quoted

Given the current situation, I'm hesitant to introduce a new driver
saying clk-imx-scmi.c.

Yes please don't, and I don't see a strong reason for that(yet).

Unlike vendor protocol, there is no way we can no upfront how the
vendors can use this in their own colourful way. So I am not sure if we
start building something generic from the start or refactor as more
vendors start using it. Hard to decide 🙁. Lets see, need to think a bit.

If Peng or Sebin or others have some idea, please propose or start the
discussion so that we can evaluate the approach.

I would give a look and hope there is an output. I will start
a new thread to discuss.

Just in my mind
Each standard protocol has its own OEM or vendor description, it might
be hard to use a generic way to support all standard protocols.

It might be a bit easier to use per protocol extension.

Anyway, let's discuss in the new thread with potential solutions.

Thanks
Peng. 

--
Regards,
Sudeep