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

[Cristian Marussi <cristian.marussi@arm.com>]

On Wed, Sep 24, 2025 at 05:45:32PM +0530, Sebin Francis wrote:
> Hi Peng,

Hi ,

> 
> On 24/09/25 17:13, Peng Fan wrote:
> > > Subject: Re: [PATCH v4 5/5] clk: scmi: Support Spread Spectrum for
> > > NXP i.MX95
> > ...
> > > > > >         SCMI_CLOCK_CFG_OEM_START = 0x80,
> > > > > > +     SCMI_CLOCK_CFG_IMX_SSC = 0x80,
> > > > > 
> > > > > TI is also planning to implement the same in our upcoming platform.
> > > > > 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.
> > > > 
> > > > 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.
> > > > 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 drivers built in kernel image, because scmi devlink issue.
> >

Yes indeed, BUT the vendor protocol extensions mechanism was meant to
serve the development of vendor custom protocols and drivers, it was
NEVER meant really to allow multiple alternative drivers implementation
on top of the same standard protocols like it happened with pinctrl-imx-scmi...
 
> > Sudeep said he would address the devlink issue in 6.19 cycle.
> > 
> > Given the current situation, I'm hesitant to introduce a new driver
> > saying clk-imx-scmi.c.
> >

Even if the devlink issues will be solved, in THIS case the problem is
handling custom vendor extensions inside a standard protocol, as it is
allowed in this case...

> > What I'm unclear about is whether moving to a vendor-specific file
> > implies creating a new driver (i.e., clk-imx-scmi.c), or if it could be
> > handled via a callback or another mechanism. Could you help
> > clarify the intended direction?
> 
> My intended was to handle it via callback or something similar, so that TI
> can its own callback for the TI's SSC implementation.
> 

This is exactly what is needed, the ability to extend with vendor
extensions callback the behavior of a standard protocol where
allowed....this is NOT currently supported and sincerely that was the
reason months ago I proposed initially that maybe we could have standardized
a new common clock extension SSC instead of using the OEM extensions since:

1. it seemed a pretty generic operation
2. any per-vendor extension callback of std protocol was NOT ready :P

...then this proposal never went anywhere with ATG...AND now looking at
this thread I think that it is good at the end that we did NOT add a new
standard extended clock config instead of the IMX OEM, since now it
seems that TI wants its own non-compatible implementation...

So yes the ideal solutiomn would be to extend in a generic way the SCMI
framework so that you can add in these cases custom handling of vendor
extensions for standard protocols (and then generalize the current
clk-scmi IMX support and add the new TI one...)...but I have not thought
about this and I certainly dont have enough bandwidth now to work on
this...beside having already in the pipeline other stuff/fixes like
a proper fix for vendor drivers coex like Peng askes (rightly so a few
months ago)

Thanks,
Cristian