schemas: introduce assigned-clock-sscs

[MrVan]

To support spread spectrum clock, introduce assigned-clock-sscs, it is an uint32-matrix with format multiple elements of below
, <...>

[krzk]

I am happy to see unified bindings but this makes me feel bitter of totally desynced work from Dario's. Three months iMX8 patchsets, multiple reviews and no single comment from you till January!

https://lore.kernel.org/all/[email protected]/

So you saw his work. Why you didn't say that you intend to come with competitive solution? Nothing to stop him from doing work which you made now partially obsolete (the bindings part).

NXP needs to be a bit more active in discussions.

[MrVan]

@krzk

I should say sorry for this. I gave R-b for most of Dario's driver patches, so I agree with his approach and I also plan to reuse his appoarch for i.MX93/i.MX91 after his patch get landed. I not intend to waste your and Dario's time.

But I got a request to enable SSC for i.MX95 based SCMI CLK just three days ago, and then I started to investigate how to enable that. Since drivers/clk/clk-scmi.c is a generic clk driver, and scmi nodes mostly only has a reg property, so impossible to add non generic property(SCMI Maintainers not happy to include other properties, especially vendor specific stuff), so I think "assigned-clock-sscs" may help here. Then I wrote the patches in two days and posted out for comments.

[passgat]

Commit 223d32eb1001 ("dt-bindings: clock: st,stm32-rcc: support spread spectrum clocking") use "st,ssc-moddepth-permyriad" (in permyriad, i.e. 0.01%) while commit 4a8bc2644ef0 ("dt-bindings: ti: dpll: add spread spectrum support") use "ti,ssc-deltam" in permille unit (10th of a percent). What about change the "The modulation percentage" in "The modulation depth", expressed in permyriad? We use a 32 bit value, so we can express it as 0.01%.

[MrVan]

It should be fine to change to modulation depth in permyriad

[robherring]

Why not put this in a clock cell for the clock? Or carve out some bits on the existing cell? How many bits are really needed here?

How is the setting determined? Is it per board? per SoC? Fixed for the consumer of the clock?

[MrVan]

@robherring

Why not put this in a clock cell for the clock? Or carve out some bits on the existing cell? How many bits are really needed here?

32 bits for i.MX95.

Put this in a clock cell maybe not good or carve out some bits on the existing cell. This would change clock xlate saying break ABI.

How is the setting determined? Is it per board? per SoC? Fixed for the consumer of the clock?

The settings are tuned by measuring using oscilloscope or else.

It is per board. Spread spectrum is mostly for reduce the radiated emissions of digital
clock signals to pass EMI.

yes, fixed for consumer of the clock.

Some references:

1. STM32
   https://community.st.com/t5/stm32-mcus/stm32h7-series-spread-spectrum-clock-generation-sscg/ta-p/699691
2. TI's CDCS502
   https://www.ti.com/lit/an/scaa103/scaa103.pdf?ts=1738485167876&ref_url=https%253A%252F%252Fwww.google.com%252F

[krzk]

Put this in a clock cell maybe not good or carve out some bits on the existing cell.

Why not good exactly?

This would change clock xlate saying break ABI.

How would it break? Old implementation should ignore trailing arguments. Are you saying it does not ignore them?

[MrVan]

Put this in a clock cell maybe not good or carve out some bits on the existing cell.

Why not good exactly?

The SSC needs three fields for each clock, using one u32 or three u32.

we could not carve out 32bits from a u32 clock entry, saying clocks = <&provider 5>. There is not enough bits for SSC.

Current bindings for clocks in linux kernel per my search,
some use one arg, some use two args, some use zero arg, saying below:
clocks = <&provider>;
clocks = <&provider X>;
clocks = <&provider X Y>;

Putting SSC in a cell would means adding extra three u32 or one u32, this would make it a bit hard to read.
And not every clock needs ssc, for those not need SSC, we also need to add extra entries.

This would change clock xlate saying break ABI.

How would it break? Old implementation should ignore trailing arguments. Are you saying it does not ignore them?

Taking current i.MX8M/iMX93 for example, SSC not supported in upstream linux as of now. Adding trailing arguments means clock provider needs update to parse the new arg and each clocks entry needs update to add new arguments to encoding SSC. For other platforms(already in tree) that would need to support SSC, similar change should be done. Not only Linux, but also other OSes that follow dt-schema.

Using assigned-clock-sscs could save a lot work for people.