[PATCH v3 0/8] Support spread spectrum clocking for i.MX8{M,N,P} PLLs

[PATCH v3 0/8] Support spread spectrum clocking for i.MX8{M,N,P} PLLs

[Dario Binacchi]

The series adds support for spread spectrum clocking for i.MX8M{N,M,P}
PLLs (audio, video and DRAM). It has been tested for the video PLL on
boards using i.MX8MN and i.MX8MP.

Changes in v3:
- Patches 1/8 has been added in version 3. The dt-bindings have
  been moved from fsl,imx8m-anatop.yaml to imx8m-clock.yaml. The
  anatop device (fsl,imx8m-anatop.yaml) is indeed more or less a
  syscon, so it represents a memory area accessible by ccm
  (imx8m-clock.yaml) to setup the PLLs.
- Patches {3,5}/8 have been added in version 3.
- Patches {4,6,8}/8 use ccm device node instead of the anatop one.

Changes in v2:
- Add "allOf:" and place it after "required:" block, like in the
  example schema.
- Move the properties definition to the top-level.
- Drop unit types as requested by the "make dt_binding_check" command.

Dario Binacchi (8):
  dt-bindings: clock: imx8m-clock: support spread spectrum clocking
  clk: imx: pll14xx: support spread spectrum clock generation
  clk: imx: imx8mm: distinguish between ccm and anatop references
  clk: imx8mm: support spread spectrum clock generation
  clk: imx: imx8mn: distinguish between ccm and anatop references
  clk: imx8mn: support spread spectrum clock generation
  clk: imx8mp: don't lose the anatop device node
  clk: imx8mp: support spread spectrum clock generation

 .../bindings/clock/imx8m-clock.yaml           |  46 ++++++++
 drivers/clk/imx/clk-imx8mm.c                  |  99 +++++++++--------
 drivers/clk/imx/clk-imx8mn.c                  | 102 +++++++++---------
 drivers/clk/imx/clk-imx8mp-audiomix.c         |   2 +-
 drivers/clk/imx/clk-imx8mp.c                  |  21 ++--
 drivers/clk/imx/clk-pll14xx.c                 | 102 +++++++++++++++++-
 drivers/clk/imx/clk.h                         |  24 ++++-
 7 files changed, 289 insertions(+), 107 deletions(-)

-- 
2.43.0

[PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Dario Binacchi]

The patch adds the DT bindings for enabling and tuning spread spectrum
clocking generation.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>

---

Changes in v3:
- Added in v3
- The dt-bindings have been moved from fsl,imx8m-anatop.yaml to
  imx8m-clock.yaml. The anatop device (fsl,imx8m-anatop.yaml) is
  indeed more or less a syscon, so it represents a memory area
  accessible by ccm (imx8m-clock.yaml) to setup the PLLs.

 .../bindings/clock/imx8m-clock.yaml           | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
index c643d4a81478..7920393e518e 100644
--- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
@@ -43,6 +43,40 @@ properties:
       ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h
       for the full list of i.MX8M clock IDs.
 
+  fsl,ssc-clocks:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description:
+      Phandles of the PLL with spread spectrum generation hardware capability.
+    minItems: 1
+    maxItems: 4
+
+  fsl,ssc-modfreq-hz:
+    description:
+      The values of modulation frequency (Hz unit) of spread spectrum
+      clocking for each PLL.
+    minItems: 1
+    maxItems: 4
+
+  fsl,ssc-modrate-percent:
+    description:
+      The percentage values of modulation rate of spread spectrum
+      clocking for each PLL.
+    minItems: 1
+    maxItems: 4
+
+  fsl,ssc-modmethod:
+    $ref: /schemas/types.yaml#/definitions/string-array
+    description:
+      The modulation techniques of spread spectrum clocking for
+      each PLL.
+    minItems: 1
+    maxItems: 4
+    items:
+      enum:
+        - down-spread
+        - up-spread
+        - center-spread
+
 required:
   - compatible
   - reg
@@ -76,6 +110,11 @@ allOf:
             - const: clk_ext2
             - const: clk_ext3
             - const: clk_ext4
+        fsl,ssc-clocks: false
+        fsl,ssc-modfreq-hz: false
+        fsl,ssc-modrate-percent: false
+        fsl,ssc-modmethod: false
+
     else:
       properties:
         clocks:
@@ -101,6 +140,8 @@ additionalProperties: false
 examples:
   # Clock Control Module node:
   - |
+    #include <dt-bindings/clock/imx8mm-clock.h>
+
     clock-controller@30380000 {
         compatible = "fsl,imx8mm-ccm";
         reg = <0x30380000 0x10000>;
@@ -109,6 +150,11 @@ examples:
                  <&clk_ext3>, <&clk_ext4>;
         clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
                       "clk_ext3", "clk_ext4";
+        fsl,ssc-clocks = <&clk IMX8MM_AUDIO_PLL1>,
+                         <&clk IMX8MM_VIDEO_PLL1>;
+        fsl,ssc-modfreq-hz = <6818>, <2419>;
+        fsl,ssc-modrate-percent = <3>, <7>;
+        fsl,ssc-modmethod = "down-spread", "center-spread";
     };
 
   - |
-- 
2.43.0

[PATCH v3 2/8] clk: imx: pll14xx: support spread spectrum clock generation

[Dario Binacchi]

This patch adds support for spread spectrum clock (SSC) generation for
the pll14xxx. The addition of the "imx_clk_hw_pll14xx_ssc" macro has
minimized the number of changes required to avoid compilation errors
following the addition of the SSC setup parameter to the
"imx_dev_clk_hw_pll14xx" macro used in the files clk-imx8m{m,n,p}.c.
The change to the clk-imx8mp-audiomix.c file prevents the patch from
causing a compilation error.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---

(no changes since v1)

 drivers/clk/imx/clk-imx8mp-audiomix.c |   2 +-
 drivers/clk/imx/clk-pll14xx.c         | 102 +++++++++++++++++++++++++-
 drivers/clk/imx/clk.h                 |  24 +++++-
 3 files changed, 124 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mp-audiomix.c b/drivers/clk/imx/clk-imx8mp-audiomix.c
index b2cb157703c5..bfcf2975c217 100644
--- a/drivers/clk/imx/clk-imx8mp-audiomix.c
+++ b/drivers/clk/imx/clk-imx8mp-audiomix.c
@@ -365,7 +365,7 @@ static int clk_imx8mp_audiomix_probe(struct platform_device *pdev)
 	clk_hw_data->hws[IMX8MP_CLK_AUDIOMIX_SAI_PLL_REF_SEL] = hw;
 
 	hw = imx_dev_clk_hw_pll14xx(dev, "sai_pll", "sai_pll_ref_sel",
-				    base + 0x400, &imx_1443x_pll);
+				    base + 0x400, &imx_1443x_pll, NULL);
 	if (IS_ERR(hw)) {
 		ret = PTR_ERR(hw);
 		goto err_clk_register;
diff --git a/drivers/clk/imx/clk-pll14xx.c b/drivers/clk/imx/clk-pll14xx.c
index d63564dbb12c..76014e243a57 100644
--- a/drivers/clk/imx/clk-pll14xx.c
+++ b/drivers/clk/imx/clk-pll14xx.c
@@ -20,6 +20,8 @@
 #define GNRL_CTL	0x0
 #define DIV_CTL0	0x4
 #define DIV_CTL1	0x8
+#define SSCG_CTRL	0xc
+
 #define LOCK_STATUS	BIT(31)
 #define LOCK_SEL_MASK	BIT(29)
 #define CLKE_MASK	BIT(11)
@@ -31,6 +33,10 @@
 #define KDIV_MASK	GENMASK(15, 0)
 #define KDIV_MIN	SHRT_MIN
 #define KDIV_MAX	SHRT_MAX
+#define SSCG_ENABLE	BIT(31)
+#define MFREQ_CTL_MASK	GENMASK(19, 12)
+#define MRAT_CTL_MASK	GENMASK(9, 4)
+#define SEL_PF_MASK	GENMASK(1, 0)
 
 #define LOCK_TIMEOUT_US		10000
 
@@ -40,6 +46,7 @@ struct clk_pll14xx {
 	enum imx_pll14xx_type		type;
 	const struct imx_pll14xx_rate_table *rate_table;
 	int rate_count;
+	struct imx_pll14xx_ssc		ssc;
 };
 
 #define to_clk_pll14xx(_hw) container_of(_hw, struct clk_pll14xx, hw)
@@ -347,6 +354,27 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw, unsigned long drate,
 	return 0;
 }
 
+static void clk_pll1443x_set_sscg(struct clk_hw *hw, unsigned long parent_rate,
+				  unsigned int pdiv, unsigned int mdiv)
+{
+	struct clk_pll14xx *pll = to_clk_pll14xx(hw);
+	struct imx_pll14xx_ssc *ssc = &pll->ssc;
+	u32 sscg_ctrl = readl_relaxed(pll->base + SSCG_CTRL);
+
+	sscg_ctrl &=
+		~(SSCG_ENABLE | MFREQ_CTL_MASK | MRAT_CTL_MASK | SEL_PF_MASK);
+	if (ssc->enable) {
+		u32 mfr = parent_rate / (ssc->mod_freq * pdiv * (1 << 5));
+		u32 mrr = (ssc->mod_rate * mdiv * (1 << 6)) / (100 * mfr);
+
+		sscg_ctrl |= SSCG_ENABLE | FIELD_PREP(MFREQ_CTL_MASK, mfr) |
+			     FIELD_PREP(MRAT_CTL_MASK, mrr) |
+			     FIELD_PREP(SEL_PF_MASK, ssc->mod_type);
+	}
+
+	writel_relaxed(sscg_ctrl, pll->base + SSCG_CTRL);
+}
+
 static int clk_pll1443x_set_rate(struct clk_hw *hw, unsigned long drate,
 				 unsigned long prate)
 {
@@ -368,6 +396,9 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw, unsigned long drate,
 		writel_relaxed(FIELD_PREP(KDIV_MASK, rate.kdiv),
 			       pll->base + DIV_CTL1);
 
+		if (pll->ssc.enable)
+			clk_pll1443x_set_sscg(hw, prate, rate.pdiv, rate.mdiv);
+
 		return 0;
 	}
 
@@ -408,6 +439,9 @@ static int clk_pll1443x_set_rate(struct clk_hw *hw, unsigned long drate,
 	gnrl_ctl &= ~BYPASS_MASK;
 	writel_relaxed(gnrl_ctl, pll->base + GNRL_CTL);
 
+	if (pll->ssc.enable)
+		clk_pll1443x_set_sscg(hw, prate, rate.pdiv, rate.mdiv);
+
 	return 0;
 }
 
@@ -487,7 +521,8 @@ static const struct clk_ops clk_pll1443x_ops = {
 
 struct clk_hw *imx_dev_clk_hw_pll14xx(struct device *dev, const char *name,
 				const char *parent_name, void __iomem *base,
-				const struct imx_pll14xx_clk *pll_clk)
+				const struct imx_pll14xx_clk *pll_clk,
+				const struct imx_pll14xx_ssc *ssc)
 {
 	struct clk_pll14xx *pll;
 	struct clk_hw *hw;
@@ -525,6 +560,8 @@ struct clk_hw *imx_dev_clk_hw_pll14xx(struct device *dev, const char *name,
 	pll->type = pll_clk->type;
 	pll->rate_table = pll_clk->rate_table;
 	pll->rate_count = pll_clk->rate_count;
+	if (ssc)
+		memcpy(&pll->ssc, ssc, sizeof(pll->ssc));
 
 	val = readl_relaxed(pll->base + GNRL_CTL);
 	val &= ~BYPASS_MASK;
@@ -542,3 +579,66 @@ struct clk_hw *imx_dev_clk_hw_pll14xx(struct device *dev, const char *name,
 	return hw;
 }
 EXPORT_SYMBOL_GPL(imx_dev_clk_hw_pll14xx);
+
+static enum imx_pll14xx_ssc_mod_type clk_pll14xx_ssc_mode(const char *name,
+							  enum imx_pll14xx_ssc_mod_type def)
+{
+	int i;
+	struct {
+		const char *name;
+		enum imx_pll14xx_ssc_mod_type id;
+	} mod_methods[] = {
+		{ .name = "down-spread", .id = IMX_PLL14XX_SSC_DOWN_SPREAD },
+		{ .name = "up-spread", .id = IMX_PLL14XX_SSC_UP_SPREAD },
+		{ .name = "center-spread", .id = IMX_PLL14XX_SSC_CENTER_SPREAD }
+	};
+
+	for (i = 0; i < ARRAY_SIZE(mod_methods); i++) {
+		if (!strcmp(name, mod_methods[i].name))
+			return mod_methods[i].id;
+	}
+
+	return def;
+}
+
+void imx_clk_pll14xx_get_ssc_conf(struct device_node *np, int pll_id,
+				  struct imx_pll14xx_ssc *ssc)
+{
+	int i, ret, offset, num_clks;
+	u32 clk_id, clk_cell_size;
+	const char *s;
+
+	if (!ssc)
+		return;
+
+	memset(ssc, 0, sizeof(*ssc));
+
+	num_clks = of_count_phandle_with_args(np, "fsl,ssc-clocks",
+					      "#clock-cells");
+	if (num_clks <= 0)
+		return;
+
+	ret = of_property_read_u32(np, "#clock-cells", &clk_cell_size);
+	if (ret)
+		return;
+
+	for (i = 0; i < num_clks; i++) {
+		offset = i * clk_cell_size + 1;
+		of_property_read_u32_index(np, "fsl,ssc-clocks", offset,
+					   &clk_id);
+		if (clk_id != pll_id)
+			continue;
+
+		of_property_read_u32_index(np, "fsl,ssc-modfreq-hz", i,
+					   &ssc->mod_freq);
+		of_property_read_u32_index(np, "fsl,ssc-modrate-percent", i,
+					   &ssc->mod_rate);
+		if (!of_property_read_string(np, "fsl,ssc-modmethod", &s))
+			ssc->mod_type = clk_pll14xx_ssc_mode(
+				s, IMX_PLL14XX_SSC_DOWN_SPREAD);
+
+		ssc->enable = true;
+		break;
+	}
+}
+EXPORT_SYMBOL_GPL(imx_clk_pll14xx_get_ssc_conf);
diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
index aa5202f284f3..8cbc75480569 100644
--- a/drivers/clk/imx/clk.h
+++ b/drivers/clk/imx/clk.h
@@ -62,6 +62,19 @@ struct imx_pll14xx_rate_table {
 	unsigned int kdiv;
 };
 
+enum imx_pll14xx_ssc_mod_type {
+	IMX_PLL14XX_SSC_DOWN_SPREAD,
+	IMX_PLL14XX_SSC_UP_SPREAD,
+	IMX_PLL14XX_SSC_CENTER_SPREAD,
+};
+
+struct imx_pll14xx_ssc {
+	bool enable;
+	unsigned int mod_freq;
+	unsigned int mod_rate;
+	enum imx_pll14xx_ssc_mod_type mod_type;
+};
+
 struct imx_pll14xx_clk {
 	enum imx_pll14xx_type type;
 	const struct imx_pll14xx_rate_table *rate_table;
@@ -222,11 +235,18 @@ extern struct imx_fracn_gppll_clk imx_fracn_gppll_integer;
 	__imx_clk_hw_divider(name, parent, reg, shift, width, flags)
 
 #define imx_clk_hw_pll14xx(name, parent_name, base, pll_clk) \
-	imx_dev_clk_hw_pll14xx(NULL, name, parent_name, base, pll_clk)
+	imx_dev_clk_hw_pll14xx(NULL, name, parent_name, base, pll_clk, NULL)
+
+#define imx_clk_hw_pll14xx_ssc(name, parent_name, base, pll_clk, ssc)	\
+	imx_dev_clk_hw_pll14xx(NULL, name, parent_name, base, pll_clk, ssc)
 
 struct clk_hw *imx_dev_clk_hw_pll14xx(struct device *dev, const char *name,
 				const char *parent_name, void __iomem *base,
-				const struct imx_pll14xx_clk *pll_clk);
+				const struct imx_pll14xx_clk *pll_clk,
+				const struct imx_pll14xx_ssc *ssc);
+
+void imx_clk_pll14xx_get_ssc_conf(struct device_node *np, int pll_id,
+				  struct imx_pll14xx_ssc *ssc);
 
 struct clk_hw *imx_clk_hw_pllv1(enum imx_pllv1_type type, const char *name,
 		const char *parent, void __iomem *base);
-- 
2.43.0

[PATCH v3 3/8] clk: imx: imx8mm: distinguish between ccm and anatop references

[Dario Binacchi]

The patch distinguishes between the references to the ccm node (np, base)
and those to the anatop node (anatop_np, anatop_base). In this way, the
code improves in readability and is less prone to errors.

The patch is also preparatory for future developments.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>

---

Changes in v3:
- Added in version 3

 drivers/clk/imx/clk-imx8mm.c | 94 ++++++++++++++++++------------------
 1 file changed, 47 insertions(+), 47 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 342049b847b9..0cf53b5b15c8 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -300,7 +300,8 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
-	void __iomem *base;
+	struct device_node *anatop_np;
+	void __iomem *base, *anatop_base;
 	int ret;
 
 	clk_hw_data = kzalloc(struct_size(clk_hw_data, hws,
@@ -319,54 +320,54 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MM_CLK_EXT3] = imx_get_clk_hw_by_name(np, "clk_ext3");
 	hws[IMX8MM_CLK_EXT4] = imx_get_clk_hw_by_name(np, "clk_ext4");
 
-	np = of_find_compatible_node(NULL, NULL, "fsl,imx8mm-anatop");
-	base = of_iomap(np, 0);
-	of_node_put(np);
-	if (WARN_ON(!base))
+	anatop_np = of_find_compatible_node(NULL, NULL, "fsl,imx8mm-anatop");
+	anatop_base = of_iomap(anatop_np, 0);
+	of_node_put(anatop_np);
+	if (WARN_ON(!anatop_base))
 		return -ENOMEM;
 
-	hws[IMX8MM_AUDIO_PLL1_REF_SEL] = imx_clk_hw_mux("audio_pll1_ref_sel", base + 0x0, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MM_AUDIO_PLL2_REF_SEL] = imx_clk_hw_mux("audio_pll2_ref_sel", base + 0x14, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MM_VIDEO_PLL1_REF_SEL] = imx_clk_hw_mux("video_pll1_ref_sel", base + 0x28, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MM_DRAM_PLL_REF_SEL] = imx_clk_hw_mux("dram_pll_ref_sel", base + 0x50, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MM_GPU_PLL_REF_SEL] = imx_clk_hw_mux("gpu_pll_ref_sel", base + 0x64, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MM_VPU_PLL_REF_SEL] = imx_clk_hw_mux("vpu_pll_ref_sel", base + 0x74, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MM_ARM_PLL_REF_SEL] = imx_clk_hw_mux("arm_pll_ref_sel", base + 0x84, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MM_SYS_PLL3_REF_SEL] = imx_clk_hw_mux("sys_pll3_ref_sel", base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-
-	hws[IMX8MM_AUDIO_PLL1] = imx_clk_hw_pll14xx("audio_pll1", "audio_pll1_ref_sel", base, &imx_1443x_pll);
-	hws[IMX8MM_AUDIO_PLL2] = imx_clk_hw_pll14xx("audio_pll2", "audio_pll2_ref_sel", base + 0x14, &imx_1443x_pll);
-	hws[IMX8MM_VIDEO_PLL1] = imx_clk_hw_pll14xx("video_pll1", "video_pll1_ref_sel", base + 0x28, &imx_1443x_pll);
-	hws[IMX8MM_DRAM_PLL] = imx_clk_hw_pll14xx("dram_pll", "dram_pll_ref_sel", base + 0x50, &imx_1443x_dram_pll);
-	hws[IMX8MM_GPU_PLL] = imx_clk_hw_pll14xx("gpu_pll", "gpu_pll_ref_sel", base + 0x64, &imx_1416x_pll);
-	hws[IMX8MM_VPU_PLL] = imx_clk_hw_pll14xx("vpu_pll", "vpu_pll_ref_sel", base + 0x74, &imx_1416x_pll);
-	hws[IMX8MM_ARM_PLL] = imx_clk_hw_pll14xx("arm_pll", "arm_pll_ref_sel", base + 0x84, &imx_1416x_pll);
+	hws[IMX8MM_AUDIO_PLL1_REF_SEL] = imx_clk_hw_mux("audio_pll1_ref_sel", anatop_base + 0x0, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MM_AUDIO_PLL2_REF_SEL] = imx_clk_hw_mux("audio_pll2_ref_sel", anatop_base + 0x14, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MM_VIDEO_PLL1_REF_SEL] = imx_clk_hw_mux("video_pll1_ref_sel", anatop_base + 0x28, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MM_DRAM_PLL_REF_SEL] = imx_clk_hw_mux("dram_pll_ref_sel", anatop_base + 0x50, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MM_GPU_PLL_REF_SEL] = imx_clk_hw_mux("gpu_pll_ref_sel", anatop_base + 0x64, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MM_VPU_PLL_REF_SEL] = imx_clk_hw_mux("vpu_pll_ref_sel", anatop_base + 0x74, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MM_ARM_PLL_REF_SEL] = imx_clk_hw_mux("arm_pll_ref_sel", anatop_base + 0x84, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MM_SYS_PLL3_REF_SEL] = imx_clk_hw_mux("sys_pll3_ref_sel", anatop_base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+
+	hws[IMX8MM_AUDIO_PLL1] = imx_clk_hw_pll14xx("audio_pll1", "audio_pll1_ref_sel", anatop_base, &imx_1443x_pll);
+	hws[IMX8MM_AUDIO_PLL2] = imx_clk_hw_pll14xx("audio_pll2", "audio_pll2_ref_sel", anatop_base + 0x14, &imx_1443x_pll);
+	hws[IMX8MM_VIDEO_PLL1] = imx_clk_hw_pll14xx("video_pll1", "video_pll1_ref_sel", anatop_base + 0x28, &imx_1443x_pll);
+	hws[IMX8MM_DRAM_PLL] = imx_clk_hw_pll14xx("dram_pll", "dram_pll_ref_sel", anatop_base + 0x50, &imx_1443x_dram_pll);
+	hws[IMX8MM_GPU_PLL] = imx_clk_hw_pll14xx("gpu_pll", "gpu_pll_ref_sel", anatop_base + 0x64, &imx_1416x_pll);
+	hws[IMX8MM_VPU_PLL] = imx_clk_hw_pll14xx("vpu_pll", "vpu_pll_ref_sel", anatop_base + 0x74, &imx_1416x_pll);
+	hws[IMX8MM_ARM_PLL] = imx_clk_hw_pll14xx("arm_pll", "arm_pll_ref_sel", anatop_base + 0x84, &imx_1416x_pll);
 	hws[IMX8MM_SYS_PLL1] = imx_clk_hw_fixed("sys_pll1", 800000000);
 	hws[IMX8MM_SYS_PLL2] = imx_clk_hw_fixed("sys_pll2", 1000000000);
-	hws[IMX8MM_SYS_PLL3] = imx_clk_hw_pll14xx("sys_pll3", "sys_pll3_ref_sel", base + 0x114, &imx_1416x_pll);
+	hws[IMX8MM_SYS_PLL3] = imx_clk_hw_pll14xx("sys_pll3", "sys_pll3_ref_sel", anatop_base + 0x114, &imx_1416x_pll);
 
 	/* PLL bypass out */
-	hws[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_hw_mux_flags("audio_pll1_bypass", base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_hw_mux_flags("audio_pll2_bypass", base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_hw_mux_flags("video_pll1_bypass", base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_hw_mux_flags("dram_pll_bypass", base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MM_GPU_PLL_BYPASS] = imx_clk_hw_mux_flags("gpu_pll_bypass", base + 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MM_VPU_PLL_BYPASS] = imx_clk_hw_mux_flags("vpu_pll_bypass", base + 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MM_ARM_PLL_BYPASS] = imx_clk_hw_mux_flags("arm_pll_bypass", base + 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MM_SYS_PLL3_BYPASS] = imx_clk_hw_mux_flags("sys_pll3_bypass", base + 0x114, 28, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MM_AUDIO_PLL1_BYPASS] = imx_clk_hw_mux_flags("audio_pll1_bypass", anatop_base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MM_AUDIO_PLL2_BYPASS] = imx_clk_hw_mux_flags("audio_pll2_bypass", anatop_base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MM_VIDEO_PLL1_BYPASS] = imx_clk_hw_mux_flags("video_pll1_bypass", anatop_base + 0x28, 16, 1, video_pll1_bypass_sels, ARRAY_SIZE(video_pll1_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MM_DRAM_PLL_BYPASS] = imx_clk_hw_mux_flags("dram_pll_bypass", anatop_base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MM_GPU_PLL_BYPASS] = imx_clk_hw_mux_flags("gpu_pll_bypass", anatop_base + 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MM_VPU_PLL_BYPASS] = imx_clk_hw_mux_flags("vpu_pll_bypass", anatop_base + 0x74, 28, 1, vpu_pll_bypass_sels, ARRAY_SIZE(vpu_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MM_ARM_PLL_BYPASS] = imx_clk_hw_mux_flags("arm_pll_bypass", anatop_base + 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MM_SYS_PLL3_BYPASS] = imx_clk_hw_mux_flags("sys_pll3_bypass", anatop_base + 0x114, 28, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels), CLK_SET_RATE_PARENT);
 
 	/* PLL out gate */
-	hws[IMX8MM_AUDIO_PLL1_OUT] = imx_clk_hw_gate("audio_pll1_out", "audio_pll1_bypass", base, 13);
-	hws[IMX8MM_AUDIO_PLL2_OUT] = imx_clk_hw_gate("audio_pll2_out", "audio_pll2_bypass", base + 0x14, 13);
-	hws[IMX8MM_VIDEO_PLL1_OUT] = imx_clk_hw_gate("video_pll1_out", "video_pll1_bypass", base + 0x28, 13);
-	hws[IMX8MM_DRAM_PLL_OUT] = imx_clk_hw_gate("dram_pll_out", "dram_pll_bypass", base + 0x50, 13);
-	hws[IMX8MM_GPU_PLL_OUT] = imx_clk_hw_gate("gpu_pll_out", "gpu_pll_bypass", base + 0x64, 11);
-	hws[IMX8MM_VPU_PLL_OUT] = imx_clk_hw_gate("vpu_pll_out", "vpu_pll_bypass", base + 0x74, 11);
-	hws[IMX8MM_ARM_PLL_OUT] = imx_clk_hw_gate("arm_pll_out", "arm_pll_bypass", base + 0x84, 11);
-	hws[IMX8MM_SYS_PLL3_OUT] = imx_clk_hw_gate("sys_pll3_out", "sys_pll3_bypass", base + 0x114, 11);
+	hws[IMX8MM_AUDIO_PLL1_OUT] = imx_clk_hw_gate("audio_pll1_out", "audio_pll1_bypass", anatop_base, 13);
+	hws[IMX8MM_AUDIO_PLL2_OUT] = imx_clk_hw_gate("audio_pll2_out", "audio_pll2_bypass", anatop_base + 0x14, 13);
+	hws[IMX8MM_VIDEO_PLL1_OUT] = imx_clk_hw_gate("video_pll1_out", "video_pll1_bypass", anatop_base + 0x28, 13);
+	hws[IMX8MM_DRAM_PLL_OUT] = imx_clk_hw_gate("dram_pll_out", "dram_pll_bypass", anatop_base + 0x50, 13);
+	hws[IMX8MM_GPU_PLL_OUT] = imx_clk_hw_gate("gpu_pll_out", "gpu_pll_bypass", anatop_base + 0x64, 11);
+	hws[IMX8MM_VPU_PLL_OUT] = imx_clk_hw_gate("vpu_pll_out", "vpu_pll_bypass", anatop_base + 0x74, 11);
+	hws[IMX8MM_ARM_PLL_OUT] = imx_clk_hw_gate("arm_pll_out", "arm_pll_bypass", anatop_base + 0x84, 11);
+	hws[IMX8MM_SYS_PLL3_OUT] = imx_clk_hw_gate("sys_pll3_out", "sys_pll3_bypass", anatop_base + 0x114, 11);
 
 	/* SYS PLL1 fixed output */
-	hws[IMX8MM_SYS_PLL1_OUT] = imx_clk_hw_gate("sys_pll1_out", "sys_pll1", base + 0x94, 11);
+	hws[IMX8MM_SYS_PLL1_OUT] = imx_clk_hw_gate("sys_pll1_out", "sys_pll1", anatop_base + 0x94, 11);
 
 	hws[IMX8MM_SYS_PLL1_40M] = imx_clk_hw_fixed_factor("sys_pll1_40m", "sys_pll1_out", 1, 20);
 	hws[IMX8MM_SYS_PLL1_80M] = imx_clk_hw_fixed_factor("sys_pll1_80m", "sys_pll1_out", 1, 10);
@@ -379,7 +380,7 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MM_SYS_PLL1_800M] = imx_clk_hw_fixed_factor("sys_pll1_800m", "sys_pll1_out", 1, 1);
 
 	/* SYS PLL2 fixed output */
-	hws[IMX8MM_SYS_PLL2_OUT] = imx_clk_hw_gate("sys_pll2_out", "sys_pll2", base + 0x104, 11);
+	hws[IMX8MM_SYS_PLL2_OUT] = imx_clk_hw_gate("sys_pll2_out", "sys_pll2", anatop_base + 0x104, 11);
 	hws[IMX8MM_SYS_PLL2_50M] = imx_clk_hw_fixed_factor("sys_pll2_50m", "sys_pll2_out", 1, 20);
 	hws[IMX8MM_SYS_PLL2_100M] = imx_clk_hw_fixed_factor("sys_pll2_100m", "sys_pll2_out", 1, 10);
 	hws[IMX8MM_SYS_PLL2_125M] = imx_clk_hw_fixed_factor("sys_pll2_125m", "sys_pll2_out", 1, 8);
@@ -390,14 +391,13 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MM_SYS_PLL2_500M] = imx_clk_hw_fixed_factor("sys_pll2_500m", "sys_pll2_out", 1, 2);
 	hws[IMX8MM_SYS_PLL2_1000M] = imx_clk_hw_fixed_factor("sys_pll2_1000m", "sys_pll2_out", 1, 1);
 
-	hws[IMX8MM_CLK_CLKOUT1_SEL] = imx_clk_hw_mux2("clkout1_sel", base + 0x128, 4, 4, clkout_sels, ARRAY_SIZE(clkout_sels));
-	hws[IMX8MM_CLK_CLKOUT1_DIV] = imx_clk_hw_divider("clkout1_div", "clkout1_sel", base + 0x128, 0, 4);
-	hws[IMX8MM_CLK_CLKOUT1] = imx_clk_hw_gate("clkout1", "clkout1_div", base + 0x128, 8);
-	hws[IMX8MM_CLK_CLKOUT2_SEL] = imx_clk_hw_mux2("clkout2_sel", base + 0x128, 20, 4, clkout_sels, ARRAY_SIZE(clkout_sels));
-	hws[IMX8MM_CLK_CLKOUT2_DIV] = imx_clk_hw_divider("clkout2_div", "clkout2_sel", base + 0x128, 16, 4);
-	hws[IMX8MM_CLK_CLKOUT2] = imx_clk_hw_gate("clkout2", "clkout2_div", base + 0x128, 24);
+	hws[IMX8MM_CLK_CLKOUT1_SEL] = imx_clk_hw_mux2("clkout1_sel", anatop_base + 0x128, 4, 4, clkout_sels, ARRAY_SIZE(clkout_sels));
+	hws[IMX8MM_CLK_CLKOUT1_DIV] = imx_clk_hw_divider("clkout1_div", "clkout1_sel", anatop_base + 0x128, 0, 4);
+	hws[IMX8MM_CLK_CLKOUT1] = imx_clk_hw_gate("clkout1", "clkout1_div", anatop_base + 0x128, 8);
+	hws[IMX8MM_CLK_CLKOUT2_SEL] = imx_clk_hw_mux2("clkout2_sel", anatop_base + 0x128, 20, 4, clkout_sels, ARRAY_SIZE(clkout_sels));
+	hws[IMX8MM_CLK_CLKOUT2_DIV] = imx_clk_hw_divider("clkout2_div", "clkout2_sel", anatop_base + 0x128, 16, 4);
+	hws[IMX8MM_CLK_CLKOUT2] = imx_clk_hw_gate("clkout2", "clkout2_div", anatop_base + 0x128, 24);
 
-	np = dev->of_node;
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (WARN_ON(IS_ERR(base)))
 		return PTR_ERR(base);
-- 
2.43.0

[PATCH v3 4/8] clk: imx8mm: support spread spectrum clock generation

[Dario Binacchi]

The patch adds support for spread spectrum clock generation for the
audio, video, and DRAM PLLs.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>

---

Changes in v3:
- Use ccm node device

 drivers/clk/imx/clk-imx8mm.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 0cf53b5b15c8..482e471d086b 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -302,6 +302,7 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
 	struct device_node *np = dev->of_node;
 	struct device_node *anatop_np;
 	void __iomem *base, *anatop_base;
+	struct imx_pll14xx_ssc pll1443x_ssc;
 	int ret;
 
 	clk_hw_data = kzalloc(struct_size(clk_hw_data, hws,
@@ -335,10 +336,14 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MM_ARM_PLL_REF_SEL] = imx_clk_hw_mux("arm_pll_ref_sel", anatop_base + 0x84, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
 	hws[IMX8MM_SYS_PLL3_REF_SEL] = imx_clk_hw_mux("sys_pll3_ref_sel", anatop_base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
 
-	hws[IMX8MM_AUDIO_PLL1] = imx_clk_hw_pll14xx("audio_pll1", "audio_pll1_ref_sel", anatop_base, &imx_1443x_pll);
-	hws[IMX8MM_AUDIO_PLL2] = imx_clk_hw_pll14xx("audio_pll2", "audio_pll2_ref_sel", anatop_base + 0x14, &imx_1443x_pll);
-	hws[IMX8MM_VIDEO_PLL1] = imx_clk_hw_pll14xx("video_pll1", "video_pll1_ref_sel", anatop_base + 0x28, &imx_1443x_pll);
-	hws[IMX8MM_DRAM_PLL] = imx_clk_hw_pll14xx("dram_pll", "dram_pll_ref_sel", anatop_base + 0x50, &imx_1443x_dram_pll);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MM_AUDIO_PLL1, &pll1443x_ssc);
+	hws[IMX8MM_AUDIO_PLL1] = imx_clk_hw_pll14xx_ssc("audio_pll1", "audio_pll1_ref_sel", anatop_base, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MM_AUDIO_PLL2, &pll1443x_ssc);
+	hws[IMX8MM_AUDIO_PLL2] = imx_clk_hw_pll14xx_ssc("audio_pll2", "audio_pll2_ref_sel", anatop_base + 0x14, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MM_VIDEO_PLL1, &pll1443x_ssc);
+	hws[IMX8MM_VIDEO_PLL1] = imx_clk_hw_pll14xx_ssc("video_pll1", "video_pll1_ref_sel", anatop_base + 0x28, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MM_DRAM_PLL, &pll1443x_ssc);
+	hws[IMX8MM_DRAM_PLL] = imx_clk_hw_pll14xx_ssc("dram_pll", "dram_pll_ref_sel", anatop_base + 0x50, &imx_1443x_dram_pll, &pll1443x_ssc);
 	hws[IMX8MM_GPU_PLL] = imx_clk_hw_pll14xx("gpu_pll", "gpu_pll_ref_sel", anatop_base + 0x64, &imx_1416x_pll);
 	hws[IMX8MM_VPU_PLL] = imx_clk_hw_pll14xx("vpu_pll", "vpu_pll_ref_sel", anatop_base + 0x74, &imx_1416x_pll);
 	hws[IMX8MM_ARM_PLL] = imx_clk_hw_pll14xx("arm_pll", "arm_pll_ref_sel", anatop_base + 0x84, &imx_1416x_pll);
-- 
2.43.0

[PATCH v3 5/8] clk: imx: imx8mn: distinguish between ccm and anatop references

[Dario Binacchi]

The patch distinguishes between the references to the ccm node (np, base)
and those to the anatop node (anatop_np, anatop_base). In this way, the
code improves in readability and is less prone to errors.

The patch is also preparatory for future developments.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---

Changes in v3:
- Added in version 3

 drivers/clk/imx/clk-imx8mn.c | 96 ++++++++++++++++++------------------
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index ab77e148e70c..feefc9ef4f51 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -320,7 +320,8 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
-	void __iomem *base;
+	struct device_node *anatop_np;
+	void __iomem *base, *anatop_base;
 	int ret;
 
 	clk_hw_data = devm_kzalloc(dev, struct_size(clk_hw_data, hws,
@@ -339,56 +340,56 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MN_CLK_EXT3] = imx_get_clk_hw_by_name(np, "clk_ext3");
 	hws[IMX8MN_CLK_EXT4] = imx_get_clk_hw_by_name(np, "clk_ext4");
 
-	np = of_find_compatible_node(NULL, NULL, "fsl,imx8mn-anatop");
-	base = devm_of_iomap(dev, np, 0, NULL);
-	of_node_put(np);
-	if (WARN_ON(IS_ERR(base))) {
-		ret = PTR_ERR(base);
+	anatop_np = of_find_compatible_node(NULL, NULL, "fsl,imx8mn-anatop");
+	anatop_base = devm_of_iomap(dev, anatop_np, 0, NULL);
+	of_node_put(anatop_np);
+	if (WARN_ON(IS_ERR(anatop_base))) {
+		ret = PTR_ERR(anatop_base);
 		goto unregister_hws;
 	}
 
-	hws[IMX8MN_AUDIO_PLL1_REF_SEL] = imx_clk_hw_mux("audio_pll1_ref_sel", base + 0x0, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MN_AUDIO_PLL2_REF_SEL] = imx_clk_hw_mux("audio_pll2_ref_sel", base + 0x14, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MN_VIDEO_PLL_REF_SEL] = imx_clk_hw_mux("video_pll_ref_sel", base + 0x28, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MN_DRAM_PLL_REF_SEL] = imx_clk_hw_mux("dram_pll_ref_sel", base + 0x50, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MN_GPU_PLL_REF_SEL] = imx_clk_hw_mux("gpu_pll_ref_sel", base + 0x64, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MN_M7_ALT_PLL_REF_SEL] = imx_clk_hw_mux("m7_alt_pll_ref_sel", base + 0x74, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MN_ARM_PLL_REF_SEL] = imx_clk_hw_mux("arm_pll_ref_sel", base + 0x84, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-	hws[IMX8MN_SYS_PLL3_REF_SEL] = imx_clk_hw_mux("sys_pll3_ref_sel", base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
-
-	hws[IMX8MN_AUDIO_PLL1] = imx_clk_hw_pll14xx("audio_pll1", "audio_pll1_ref_sel", base, &imx_1443x_pll);
-	hws[IMX8MN_AUDIO_PLL2] = imx_clk_hw_pll14xx("audio_pll2", "audio_pll2_ref_sel", base + 0x14, &imx_1443x_pll);
-	hws[IMX8MN_VIDEO_PLL] = imx_clk_hw_pll14xx("video_pll", "video_pll_ref_sel", base + 0x28, &imx_1443x_pll);
-	hws[IMX8MN_DRAM_PLL] = imx_clk_hw_pll14xx("dram_pll", "dram_pll_ref_sel", base + 0x50, &imx_1443x_dram_pll);
-	hws[IMX8MN_GPU_PLL] = imx_clk_hw_pll14xx("gpu_pll", "gpu_pll_ref_sel", base + 0x64, &imx_1416x_pll);
-	hws[IMX8MN_M7_ALT_PLL] = imx_clk_hw_pll14xx("m7_alt_pll", "m7_alt_pll_ref_sel", base + 0x74, &imx_1416x_pll);
-	hws[IMX8MN_ARM_PLL] = imx_clk_hw_pll14xx("arm_pll", "arm_pll_ref_sel", base + 0x84, &imx_1416x_pll);
+	hws[IMX8MN_AUDIO_PLL1_REF_SEL] = imx_clk_hw_mux("audio_pll1_ref_sel", anatop_base + 0x0, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MN_AUDIO_PLL2_REF_SEL] = imx_clk_hw_mux("audio_pll2_ref_sel", anatop_base + 0x14, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MN_VIDEO_PLL_REF_SEL] = imx_clk_hw_mux("video_pll_ref_sel", anatop_base + 0x28, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MN_DRAM_PLL_REF_SEL] = imx_clk_hw_mux("dram_pll_ref_sel", anatop_base + 0x50, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MN_GPU_PLL_REF_SEL] = imx_clk_hw_mux("gpu_pll_ref_sel", anatop_base + 0x64, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MN_M7_ALT_PLL_REF_SEL] = imx_clk_hw_mux("m7_alt_pll_ref_sel", anatop_base + 0x74, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MN_ARM_PLL_REF_SEL] = imx_clk_hw_mux("arm_pll_ref_sel", anatop_base + 0x84, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+	hws[IMX8MN_SYS_PLL3_REF_SEL] = imx_clk_hw_mux("sys_pll3_ref_sel", anatop_base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
+
+	hws[IMX8MN_AUDIO_PLL1] = imx_clk_hw_pll14xx("audio_pll1", "audio_pll1_ref_sel", anatop_base, &imx_1443x_pll);
+	hws[IMX8MN_AUDIO_PLL2] = imx_clk_hw_pll14xx("audio_pll2", "audio_pll2_ref_sel", anatop_base + 0x14, &imx_1443x_pll);
+	hws[IMX8MN_VIDEO_PLL] = imx_clk_hw_pll14xx("video_pll", "video_pll_ref_sel", anatop_base + 0x28, &imx_1443x_pll);
+	hws[IMX8MN_DRAM_PLL] = imx_clk_hw_pll14xx("dram_pll", "dram_pll_ref_sel", anatop_base + 0x50, &imx_1443x_dram_pll);
+	hws[IMX8MN_GPU_PLL] = imx_clk_hw_pll14xx("gpu_pll", "gpu_pll_ref_sel", anatop_base + 0x64, &imx_1416x_pll);
+	hws[IMX8MN_M7_ALT_PLL] = imx_clk_hw_pll14xx("m7_alt_pll", "m7_alt_pll_ref_sel", anatop_base + 0x74, &imx_1416x_pll);
+	hws[IMX8MN_ARM_PLL] = imx_clk_hw_pll14xx("arm_pll", "arm_pll_ref_sel", anatop_base + 0x84, &imx_1416x_pll);
 	hws[IMX8MN_SYS_PLL1] = imx_clk_hw_fixed("sys_pll1", 800000000);
 	hws[IMX8MN_SYS_PLL2] = imx_clk_hw_fixed("sys_pll2", 1000000000);
-	hws[IMX8MN_SYS_PLL3] = imx_clk_hw_pll14xx("sys_pll3", "sys_pll3_ref_sel", base + 0x114, &imx_1416x_pll);
+	hws[IMX8MN_SYS_PLL3] = imx_clk_hw_pll14xx("sys_pll3", "sys_pll3_ref_sel", anatop_base + 0x114, &imx_1416x_pll);
 
 	/* PLL bypass out */
-	hws[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_hw_mux_flags("audio_pll1_bypass", base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_hw_mux_flags("audio_pll2_bypass", base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MN_VIDEO_PLL_BYPASS] = imx_clk_hw_mux_flags("video_pll_bypass", base + 0x28, 16, 1, video_pll_bypass_sels, ARRAY_SIZE(video_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_hw_mux_flags("dram_pll_bypass", base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MN_GPU_PLL_BYPASS] = imx_clk_hw_mux_flags("gpu_pll_bypass", base + 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MN_M7_ALT_PLL_BYPASS] = imx_clk_hw_mux_flags("m7_alt_pll_bypass", base + 0x74, 28, 1, m7_alt_pll_bypass_sels, ARRAY_SIZE(m7_alt_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MN_ARM_PLL_BYPASS] = imx_clk_hw_mux_flags("arm_pll_bypass", base + 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), CLK_SET_RATE_PARENT);
-	hws[IMX8MN_SYS_PLL3_BYPASS] = imx_clk_hw_mux_flags("sys_pll3_bypass", base + 0x114, 28, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MN_AUDIO_PLL1_BYPASS] = imx_clk_hw_mux_flags("audio_pll1_bypass", anatop_base, 16, 1, audio_pll1_bypass_sels, ARRAY_SIZE(audio_pll1_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MN_AUDIO_PLL2_BYPASS] = imx_clk_hw_mux_flags("audio_pll2_bypass", anatop_base + 0x14, 16, 1, audio_pll2_bypass_sels, ARRAY_SIZE(audio_pll2_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MN_VIDEO_PLL_BYPASS] = imx_clk_hw_mux_flags("video_pll_bypass", anatop_base + 0x28, 16, 1, video_pll_bypass_sels, ARRAY_SIZE(video_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MN_DRAM_PLL_BYPASS] = imx_clk_hw_mux_flags("dram_pll_bypass", anatop_base + 0x50, 16, 1, dram_pll_bypass_sels, ARRAY_SIZE(dram_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MN_GPU_PLL_BYPASS] = imx_clk_hw_mux_flags("gpu_pll_bypass", anatop_base + 0x64, 28, 1, gpu_pll_bypass_sels, ARRAY_SIZE(gpu_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MN_M7_ALT_PLL_BYPASS] = imx_clk_hw_mux_flags("m7_alt_pll_bypass", anatop_base + 0x74, 28, 1, m7_alt_pll_bypass_sels, ARRAY_SIZE(m7_alt_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MN_ARM_PLL_BYPASS] = imx_clk_hw_mux_flags("arm_pll_bypass", anatop_base + 0x84, 28, 1, arm_pll_bypass_sels, ARRAY_SIZE(arm_pll_bypass_sels), CLK_SET_RATE_PARENT);
+	hws[IMX8MN_SYS_PLL3_BYPASS] = imx_clk_hw_mux_flags("sys_pll3_bypass", anatop_base + 0x114, 28, 1, sys_pll3_bypass_sels, ARRAY_SIZE(sys_pll3_bypass_sels), CLK_SET_RATE_PARENT);
 
 	/* PLL out gate */
-	hws[IMX8MN_AUDIO_PLL1_OUT] = imx_clk_hw_gate("audio_pll1_out", "audio_pll1_bypass", base, 13);
-	hws[IMX8MN_AUDIO_PLL2_OUT] = imx_clk_hw_gate("audio_pll2_out", "audio_pll2_bypass", base + 0x14, 13);
-	hws[IMX8MN_VIDEO_PLL_OUT] = imx_clk_hw_gate("video_pll_out", "video_pll_bypass", base + 0x28, 13);
-	hws[IMX8MN_DRAM_PLL_OUT] = imx_clk_hw_gate("dram_pll_out", "dram_pll_bypass", base + 0x50, 13);
-	hws[IMX8MN_GPU_PLL_OUT] = imx_clk_hw_gate("gpu_pll_out", "gpu_pll_bypass", base + 0x64, 11);
-	hws[IMX8MN_M7_ALT_PLL_OUT] = imx_clk_hw_gate("m7_alt_pll_out", "m7_alt_pll_bypass", base + 0x74, 11);
-	hws[IMX8MN_ARM_PLL_OUT] = imx_clk_hw_gate("arm_pll_out", "arm_pll_bypass", base + 0x84, 11);
-	hws[IMX8MN_SYS_PLL3_OUT] = imx_clk_hw_gate("sys_pll3_out", "sys_pll3_bypass", base + 0x114, 11);
+	hws[IMX8MN_AUDIO_PLL1_OUT] = imx_clk_hw_gate("audio_pll1_out", "audio_pll1_bypass", anatop_base, 13);
+	hws[IMX8MN_AUDIO_PLL2_OUT] = imx_clk_hw_gate("audio_pll2_out", "audio_pll2_bypass", anatop_base + 0x14, 13);
+	hws[IMX8MN_VIDEO_PLL_OUT] = imx_clk_hw_gate("video_pll_out", "video_pll_bypass", anatop_base + 0x28, 13);
+	hws[IMX8MN_DRAM_PLL_OUT] = imx_clk_hw_gate("dram_pll_out", "dram_pll_bypass", anatop_base + 0x50, 13);
+	hws[IMX8MN_GPU_PLL_OUT] = imx_clk_hw_gate("gpu_pll_out", "gpu_pll_bypass", anatop_base + 0x64, 11);
+	hws[IMX8MN_M7_ALT_PLL_OUT] = imx_clk_hw_gate("m7_alt_pll_out", "m7_alt_pll_bypass", anatop_base + 0x74, 11);
+	hws[IMX8MN_ARM_PLL_OUT] = imx_clk_hw_gate("arm_pll_out", "arm_pll_bypass", anatop_base + 0x84, 11);
+	hws[IMX8MN_SYS_PLL3_OUT] = imx_clk_hw_gate("sys_pll3_out", "sys_pll3_bypass", anatop_base + 0x114, 11);
 
 	/* SYS PLL1 fixed output */
-	hws[IMX8MN_SYS_PLL1_OUT] = imx_clk_hw_gate("sys_pll1_out", "sys_pll1", base + 0x94, 11);
+	hws[IMX8MN_SYS_PLL1_OUT] = imx_clk_hw_gate("sys_pll1_out", "sys_pll1", anatop_base + 0x94, 11);
 	hws[IMX8MN_SYS_PLL1_40M] = imx_clk_hw_fixed_factor("sys_pll1_40m", "sys_pll1_out", 1, 20);
 	hws[IMX8MN_SYS_PLL1_80M] = imx_clk_hw_fixed_factor("sys_pll1_80m", "sys_pll1_out", 1, 10);
 	hws[IMX8MN_SYS_PLL1_100M] = imx_clk_hw_fixed_factor("sys_pll1_100m", "sys_pll1_out", 1, 8);
@@ -400,7 +401,7 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MN_SYS_PLL1_800M] = imx_clk_hw_fixed_factor("sys_pll1_800m", "sys_pll1_out", 1, 1);
 
 	/* SYS PLL2 fixed output */
-	hws[IMX8MN_SYS_PLL2_OUT] = imx_clk_hw_gate("sys_pll2_out", "sys_pll2", base + 0x104, 11);
+	hws[IMX8MN_SYS_PLL2_OUT] = imx_clk_hw_gate("sys_pll2_out", "sys_pll2", anatop_base + 0x104, 11);
 	hws[IMX8MN_SYS_PLL2_50M] = imx_clk_hw_fixed_factor("sys_pll2_50m", "sys_pll2_out", 1, 20);
 	hws[IMX8MN_SYS_PLL2_100M] = imx_clk_hw_fixed_factor("sys_pll2_100m", "sys_pll2_out", 1, 10);
 	hws[IMX8MN_SYS_PLL2_125M] = imx_clk_hw_fixed_factor("sys_pll2_125m", "sys_pll2_out", 1, 8);
@@ -411,14 +412,13 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MN_SYS_PLL2_500M] = imx_clk_hw_fixed_factor("sys_pll2_500m", "sys_pll2_out", 1, 2);
 	hws[IMX8MN_SYS_PLL2_1000M] = imx_clk_hw_fixed_factor("sys_pll2_1000m", "sys_pll2_out", 1, 1);
 
-	hws[IMX8MN_CLK_CLKOUT1_SEL] = imx_clk_hw_mux2("clkout1_sel", base + 0x128, 4, 4, clkout_sels, ARRAY_SIZE(clkout_sels));
-	hws[IMX8MN_CLK_CLKOUT1_DIV] = imx_clk_hw_divider("clkout1_div", "clkout1_sel", base + 0x128, 0, 4);
-	hws[IMX8MN_CLK_CLKOUT1] = imx_clk_hw_gate("clkout1", "clkout1_div", base + 0x128, 8);
-	hws[IMX8MN_CLK_CLKOUT2_SEL] = imx_clk_hw_mux2("clkout2_sel", base + 0x128, 20, 4, clkout_sels, ARRAY_SIZE(clkout_sels));
-	hws[IMX8MN_CLK_CLKOUT2_DIV] = imx_clk_hw_divider("clkout2_div", "clkout2_sel", base + 0x128, 16, 4);
-	hws[IMX8MN_CLK_CLKOUT2] = imx_clk_hw_gate("clkout2", "clkout2_div", base + 0x128, 24);
+	hws[IMX8MN_CLK_CLKOUT1_SEL] = imx_clk_hw_mux2("clkout1_sel", anatop_base + 0x128, 4, 4, clkout_sels, ARRAY_SIZE(clkout_sels));
+	hws[IMX8MN_CLK_CLKOUT1_DIV] = imx_clk_hw_divider("clkout1_div", "clkout1_sel", anatop_base + 0x128, 0, 4);
+	hws[IMX8MN_CLK_CLKOUT1] = imx_clk_hw_gate("clkout1", "clkout1_div", anatop_base + 0x128, 8);
+	hws[IMX8MN_CLK_CLKOUT2_SEL] = imx_clk_hw_mux2("clkout2_sel", anatop_base + 0x128, 20, 4, clkout_sels, ARRAY_SIZE(clkout_sels));
+	hws[IMX8MN_CLK_CLKOUT2_DIV] = imx_clk_hw_divider("clkout2_div", "clkout2_sel", anatop_base + 0x128, 16, 4);
+	hws[IMX8MN_CLK_CLKOUT2] = imx_clk_hw_gate("clkout2", "clkout2_div", anatop_base + 0x128, 24);
 
-	np = dev->of_node;
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (WARN_ON(IS_ERR(base))) {
 		ret = PTR_ERR(base);
-- 
2.43.0

[PATCH v3 6/8] clk: imx8mn: support spread spectrum clock generation

[Dario Binacchi]

The patch adds support for spread spectrum clock generation for the
audio, video, and DRAM PLLs.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>

---

Changes in v3:
- Use ccm node device

 drivers/clk/imx/clk-imx8mn.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index feefc9ef4f51..91b819d1c523 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -322,6 +322,7 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
 	struct device_node *np = dev->of_node;
 	struct device_node *anatop_np;
 	void __iomem *base, *anatop_base;
+	struct imx_pll14xx_ssc pll1443x_ssc;
 	int ret;
 
 	clk_hw_data = devm_kzalloc(dev, struct_size(clk_hw_data, hws,
@@ -357,13 +358,18 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MN_ARM_PLL_REF_SEL] = imx_clk_hw_mux("arm_pll_ref_sel", anatop_base + 0x84, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
 	hws[IMX8MN_SYS_PLL3_REF_SEL] = imx_clk_hw_mux("sys_pll3_ref_sel", anatop_base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
 
-	hws[IMX8MN_AUDIO_PLL1] = imx_clk_hw_pll14xx("audio_pll1", "audio_pll1_ref_sel", anatop_base, &imx_1443x_pll);
-	hws[IMX8MN_AUDIO_PLL2] = imx_clk_hw_pll14xx("audio_pll2", "audio_pll2_ref_sel", anatop_base + 0x14, &imx_1443x_pll);
-	hws[IMX8MN_VIDEO_PLL] = imx_clk_hw_pll14xx("video_pll", "video_pll_ref_sel", anatop_base + 0x28, &imx_1443x_pll);
-	hws[IMX8MN_DRAM_PLL] = imx_clk_hw_pll14xx("dram_pll", "dram_pll_ref_sel", anatop_base + 0x50, &imx_1443x_dram_pll);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MN_AUDIO_PLL1, &pll1443x_ssc);
+	hws[IMX8MN_AUDIO_PLL1] = imx_clk_hw_pll14xx_ssc("audio_pll1", "audio_pll1_ref_sel", anatop_base, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MN_AUDIO_PLL2, &pll1443x_ssc);
+	hws[IMX8MN_AUDIO_PLL2] = imx_clk_hw_pll14xx_ssc("audio_pll2", "audio_pll2_ref_sel", anatop_base + 0x14, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MN_VIDEO_PLL, &pll1443x_ssc);
+	hws[IMX8MN_VIDEO_PLL] = imx_clk_hw_pll14xx_ssc("video_pll", "video_pll_ref_sel", anatop_base + 0x28, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MN_DRAM_PLL, &pll1443x_ssc);
+	hws[IMX8MN_DRAM_PLL] = imx_clk_hw_pll14xx_ssc("dram_pll", "dram_pll_ref_sel", anatop_base + 0x50, &imx_1443x_dram_pll, &pll1443x_ssc);
 	hws[IMX8MN_GPU_PLL] = imx_clk_hw_pll14xx("gpu_pll", "gpu_pll_ref_sel", anatop_base + 0x64, &imx_1416x_pll);
 	hws[IMX8MN_M7_ALT_PLL] = imx_clk_hw_pll14xx("m7_alt_pll", "m7_alt_pll_ref_sel", anatop_base + 0x74, &imx_1416x_pll);
 	hws[IMX8MN_ARM_PLL] = imx_clk_hw_pll14xx("arm_pll", "arm_pll_ref_sel", anatop_base + 0x84, &imx_1416x_pll);
+
 	hws[IMX8MN_SYS_PLL1] = imx_clk_hw_fixed("sys_pll1", 800000000);
 	hws[IMX8MN_SYS_PLL2] = imx_clk_hw_fixed("sys_pll2", 1000000000);
 	hws[IMX8MN_SYS_PLL3] = imx_clk_hw_pll14xx("sys_pll3", "sys_pll3_ref_sel", anatop_base + 0x114, &imx_1416x_pll);
-- 
2.43.0

[PATCH v3 7/8] clk: imx8mp: don't lose the anatop device node

[Dario Binacchi]

Setting the "clk" (clock-controller@30380000) device node caused the
reference to the "anatop" (clock-controller@30360000) device node to be
lost. This patch, similar to what was already done for the base address,
now distinguishes between the "anatop" device node and the "clk" device
node. This change is preparatory for future developments.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
---

(no changes since v1)

 drivers/clk/imx/clk-imx8mp.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index 516dbd170c8a..b2778958a572 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -408,13 +408,13 @@ static struct clk_hw_onecell_data *clk_hw_data;
 static int imx8mp_clocks_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	struct device_node *np;
+	struct device_node *np, *anatop_np;
 	void __iomem *anatop_base, *ccm_base;
 	int err;
 
-	np = of_find_compatible_node(NULL, NULL, "fsl,imx8mp-anatop");
-	anatop_base = devm_of_iomap(dev, np, 0, NULL);
-	of_node_put(np);
+	anatop_np = of_find_compatible_node(NULL, NULL, "fsl,imx8mp-anatop");
+	anatop_base = devm_of_iomap(dev, anatop_np, 0, NULL);
+	of_node_put(anatop_np);
 	if (WARN_ON(IS_ERR(anatop_base)))
 		return PTR_ERR(anatop_base);
 
-- 
2.43.0

[PATCH v3 8/8] clk: imx8mp: support spread spectrum clock generation

[Dario Binacchi]

The patch adds support for spread spectrum clock generation for the
audio, video, and DRAM PLLs.

Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>

---

Changes in v3:
- Use ccm node device

Changes in v2:
- Add "allOf:" and place it after "required:" block, like in the
  example schema.
- Move the properties definition to the top-level.
- Drop unit types as requested by the "make dt_binding_check" command.

 drivers/clk/imx/clk-imx8mp.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index b2778958a572..e53a688d2cfe 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -410,6 +410,7 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *np, *anatop_np;
 	void __iomem *anatop_base, *ccm_base;
+	struct imx_pll14xx_ssc pll1443x_ssc;
 	int err;
 
 	anatop_np = of_find_compatible_node(NULL, NULL, "fsl,imx8mp-anatop");
@@ -449,10 +450,14 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)
 	hws[IMX8MP_SYS_PLL2_REF_SEL] = imx_clk_hw_mux("sys_pll2_ref_sel", anatop_base + 0x104, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
 	hws[IMX8MP_SYS_PLL3_REF_SEL] = imx_clk_hw_mux("sys_pll3_ref_sel", anatop_base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
 
-	hws[IMX8MP_AUDIO_PLL1] = imx_clk_hw_pll14xx("audio_pll1", "audio_pll1_ref_sel", anatop_base, &imx_1443x_pll);
-	hws[IMX8MP_AUDIO_PLL2] = imx_clk_hw_pll14xx("audio_pll2", "audio_pll2_ref_sel", anatop_base + 0x14, &imx_1443x_pll);
-	hws[IMX8MP_VIDEO_PLL1] = imx_clk_hw_pll14xx("video_pll1", "video_pll1_ref_sel", anatop_base + 0x28, &imx_1443x_pll);
-	hws[IMX8MP_DRAM_PLL] = imx_clk_hw_pll14xx("dram_pll", "dram_pll_ref_sel", anatop_base + 0x50, &imx_1443x_dram_pll);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MP_AUDIO_PLL1, &pll1443x_ssc);
+	hws[IMX8MP_AUDIO_PLL1] = imx_clk_hw_pll14xx_ssc("audio_pll1", "audio_pll1_ref_sel", anatop_base, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MP_AUDIO_PLL2, &pll1443x_ssc);
+	hws[IMX8MP_AUDIO_PLL2] = imx_clk_hw_pll14xx_ssc("audio_pll2", "audio_pll2_ref_sel", anatop_base + 0x14, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MP_VIDEO_PLL1, &pll1443x_ssc);
+	hws[IMX8MP_VIDEO_PLL1] = imx_clk_hw_pll14xx_ssc("video_pll1", "video_pll1_ref_sel", anatop_base + 0x28, &imx_1443x_pll, &pll1443x_ssc);
+	imx_clk_pll14xx_get_ssc_conf(np, IMX8MP_DRAM_PLL, &pll1443x_ssc);
+	hws[IMX8MP_DRAM_PLL] = imx_clk_hw_pll14xx_ssc("dram_pll", "dram_pll_ref_sel", anatop_base + 0x50, &imx_1443x_dram_pll, &pll1443x_ssc);
 	hws[IMX8MP_GPU_PLL] = imx_clk_hw_pll14xx("gpu_pll", "gpu_pll_ref_sel", anatop_base + 0x64, &imx_1416x_pll);
 	hws[IMX8MP_VPU_PLL] = imx_clk_hw_pll14xx("vpu_pll", "vpu_pll_ref_sel", anatop_base + 0x74, &imx_1416x_pll);
 	hws[IMX8MP_ARM_PLL] = imx_clk_hw_pll14xx("arm_pll", "arm_pll_ref_sel", anatop_base + 0x84, &imx_1416x_pll);
-- 
2.43.0

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Krzysztof Kozlowski]

On Wed, Nov 06, 2024 at 09:57:57AM +0100, Dario Binacchi wrote:
> The patch adds the DT bindings for enabling and tuning spread spectrum
> clocking generation.

We had long talks about this but nothing of it got reflected in commit
msg. Sorry, I don't remember what I was talking in some particular patch
month ago, so you will get the same questions over and over...

> 
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> 
> ---
> 
> Changes in v3:
> - Added in v3
> - The dt-bindings have been moved from fsl,imx8m-anatop.yaml to
>   imx8m-clock.yaml. The anatop device (fsl,imx8m-anatop.yaml) is
>   indeed more or less a syscon, so it represents a memory area
>   accessible by ccm (imx8m-clock.yaml) to setup the PLLs.
> 
>  .../bindings/clock/imx8m-clock.yaml           | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> index c643d4a81478..7920393e518e 100644
> --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> @@ -43,6 +43,40 @@ properties:
>        ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h
>        for the full list of i.MX8M clock IDs.
>  
> +  fsl,ssc-clocks:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description:
> +      Phandles of the PLL with spread spectrum generation hardware capability.
> +    minItems: 1
> +    maxItems: 4

1. How is it possible that you change spread spectrum of some clocks from
main Clock Controller, while this device is not a consumer of them?
Basically this means that this device does not have these clocks but yet
you claim that it needs to configure spread for them! It's contradictory
to me and nohing got explained in commit msg about it. I am pretty sure
I asked about this alrady.

2. Why is this array flexible in size?

Best regards,
Krzysztof

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Krzysztof Kozlowski]

On 06/11/2024 15:10, Krzysztof Kozlowski wrote:
> On Wed, Nov 06, 2024 at 09:57:57AM +0100, Dario Binacchi wrote:
>> The patch adds the DT bindings for enabling and tuning spread spectrum
>> clocking generation.
> 
> We had long talks about this but nothing of it got reflected in commit
> msg. Sorry, I don't remember what I was talking in some particular patch
> month ago, so you will get the same questions over and over...
> 
>>
>> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>>
>> ---
>>
>> Changes in v3:
>> - Added in v3
>> - The dt-bindings have been moved from fsl,imx8m-anatop.yaml to
>>   imx8m-clock.yaml. The anatop device (fsl,imx8m-anatop.yaml) is
>>   indeed more or less a syscon, so it represents a memory area
>>   accessible by ccm (imx8m-clock.yaml) to setup the PLLs.
>>
>>  .../bindings/clock/imx8m-clock.yaml           | 46 +++++++++++++++++++
>>  1 file changed, 46 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
>> index c643d4a81478..7920393e518e 100644
>> --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
>> +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
>> @@ -43,6 +43,40 @@ properties:
>>        ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h
>>        for the full list of i.MX8M clock IDs.
>>  
>> +  fsl,ssc-clocks:
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +    description:
>> +      Phandles of the PLL with spread spectrum generation hardware capability.
>> +    minItems: 1
>> +    maxItems: 4
> 
> 1. How is it possible that you change spread spectrum of some clocks from
> main Clock Controller, while this device is not a consumer of them?
> Basically this means that this device does not have these clocks but yet
> you claim that it needs to configure spread for them! It's contradictory
> to me and nohing got explained in commit msg about it. I am pretty sure
> I asked about this alrady.

I digged my previous answer and it was pretty clear here:

18:44 <krzk> You can, but I still have the same concerns. How this
device - which does not take any clock input, has no clocks at all - can
depend on spread spectrum of some PLLs? Thsi device does not have clocks.
18:50 <krzk> device has no clocks, I checked now third time
18:50 <krzk> If device has clocks, it must have clocks property

So again, you do not need this property at all. I repeated it multiple
times - you are supposed to use clocks property.

> 
> 2. Why is this array flexible in size?
> 
> Best regards,
> Krzysztof
> 

Best regards,
Krzysztof

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Dario Binacchi]

Hello Krzysztof,

On Wed, Nov 6, 2024 at 3:13 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 06/11/2024 15:10, Krzysztof Kozlowski wrote:
> > On Wed, Nov 06, 2024 at 09:57:57AM +0100, Dario Binacchi wrote:
> >> The patch adds the DT bindings for enabling and tuning spread spectrum
> >> clocking generation.
> >
> > We had long talks about this but nothing of it got reflected in commit
> > msg. Sorry, I don't remember what I was talking in some particular patch
> > month ago, so you will get the same questions over and over...
> >
> >>
> >> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> >>
> >> ---
> >>
> >> Changes in v3:
> >> - Added in v3
> >> - The dt-bindings have been moved from fsl,imx8m-anatop.yaml to
> >>   imx8m-clock.yaml. The anatop device (fsl,imx8m-anatop.yaml) is
> >>   indeed more or less a syscon, so it represents a memory area
> >>   accessible by ccm (imx8m-clock.yaml) to setup the PLLs.
> >>
> >>  .../bindings/clock/imx8m-clock.yaml           | 46 +++++++++++++++++++
> >>  1 file changed, 46 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> >> index c643d4a81478..7920393e518e 100644
> >> --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> >> +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> >> @@ -43,6 +43,40 @@ properties:
> >>        ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h
> >>        for the full list of i.MX8M clock IDs.
> >>
> >> +  fsl,ssc-clocks:
> >> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> >> +    description:
> >> +      Phandles of the PLL with spread spectrum generation hardware capability.
> >> +    minItems: 1
> >> +    maxItems: 4
> >
> > 1. How is it possible that you change spread spectrum of some clocks from
> > main Clock Controller, while this device is not a consumer of them?
> > Basically this means that this device does not have these clocks but yet
> > you claim that it needs to configure spread for them! It's contradictory
> > to me and nohing got explained in commit msg about it. I am pretty sure
> > I asked about this alrady.
>
> I digged my previous answer and it was pretty clear here:
>
> 18:44 <krzk> You can, but I still have the same concerns. How this
> device - which does not take any clock input, has no clocks at all - can
> depend on spread spectrum of some PLLs? Thsi device does not have clocks.
> 18:50 <krzk> device has no clocks, I checked now third time
> 18:50 <krzk> If device has clocks, it must have clocks property
>

The device where the spread spectrum properties are to be set already
contains "clocks" properties:

clk: clock-controller@30380000 {
    compatible = "fsl,imx8mn-ccm";
    reg = <0x30380000 0x10000>;
    interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
                       <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
    #clock-cells = <1>;
    clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
                  <&clk_ext3>, <&clk_ext4>;
    clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
                             "clk_ext3", "clk_ext4";
    assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
                                  <&clk IMX8MN_CLK_A53_CORE>,
                                  <&clk IMX8MN_CLK_NOC>,
                                  <&clk IMX8MN_CLK_AUDIO_AHB>,
                                  <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
                                  <&clk IMX8MN_SYS_PLL3>,
                                  <&clk IMX8MN_AUDIO_PLL1>,
                                  <&clk IMX8MN_AUDIO_PLL2>;
    assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
                                             <&clk IMX8MN_ARM_PLL_OUT>,
                                             <&clk IMX8MN_SYS_PLL3_OUT>,
                                             <&clk IMX8MN_SYS_PLL1_800M>;
    assigned-clock-rates = <0>, <0>, <0>,
                                         <400000000>,
                                         <400000000>,
                                         <600000000>,
                                         <393216000>,
                                         <361267200>;
};

The spread spectrum is not configurable on these clocks or, more
generally, may not be
configurable (only 4 PLLs have this capability). Therefore, I need the
"fsl,ssc-clocks"
property to list the PLLs on which I want to enable and configure
spread spectrum.

Furthermore, spread spectrum cannot be considered a new device but
rather a property
available only for some of the clocks managed by the clock controller
manager (CCM).

Thanks and regards,
Dario

> So again, you do not need this property at all. I repeated it multiple
> times - you are supposed to use clocks property.
>
> >
> > 2. Why is this array flexible in size?
> >
> > Best regards,
> > Krzysztof
> >
>
> Best regards,
> Krzysztof
>


--

Dario Binacchi

Senior Embedded Linux Developer

dario.binacchi@amarulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info@amarulasolutions.com

www.amarulasolutions.com

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Krzysztof Kozlowski]

On 07/11/2024 15:57, Dario Binacchi wrote:
>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
>                   <&clk_ext3>, <&clk_ext4>;
>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
>                              "clk_ext3", "clk_ext4";
>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
>                                   <&clk IMX8MN_CLK_A53_CORE>,
>                                   <&clk IMX8MN_CLK_NOC>,
>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
>                                   <&clk IMX8MN_SYS_PLL3>,
>                                   <&clk IMX8MN_AUDIO_PLL1>,
>                                   <&clk IMX8MN_AUDIO_PLL2>;
>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
>                                              <&clk IMX8MN_ARM_PLL_OUT>,
>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
>                                              <&clk IMX8MN_SYS_PLL1_800M>;
>     assigned-clock-rates = <0>, <0>, <0>,
>                                          <400000000>,
>                                          <400000000>,
>                                          <600000000>,
>                                          <393216000>,
>                                          <361267200>;
> };
> 
> The spread spectrum is not configurable on these clocks or, more
> generally, may not be
> configurable (only 4 PLLs have this capability). Therefore, I need the
> "fsl,ssc-clocks"

No. That's not true. You do not need it.

First, the clock inputs for this device are listed in clocks *only*.
What is no there, is not an input to the device. Including also Linux
aspect (missing devlinks etc). Therefore how can you configure spread
spectrum on clocks which are not connected to this device?

Second, I do no ask you to configure spread spectrum on other clocks,
only on the ones you intent to. List is fixed and ordered, so no problem
with that.

> property to list the PLLs on which I want to enable and configure
> spread spectrum.
> 
> Furthermore, spread spectrum cannot be considered a new device but
> rather a property
> available only for some of the clocks managed by the clock controller
> manager (CCM).
> 

My comment stands and that's a disagreement from me. Feel free to get
second DT maintainer opinion, though.

Best regards,
Krzysztof

RE: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Peng Fan]

> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
> spread spectrum clocking
> 
> On 07/11/2024 15:57, Dario Binacchi wrote:
> >     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
> >                   <&clk_ext3>, <&clk_ext4>;
> >     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
> >                              "clk_ext3", "clk_ext4";
> >     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
> >                                   <&clk IMX8MN_CLK_A53_CORE>,
> >                                   <&clk IMX8MN_CLK_NOC>,
> >                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
> >                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
> >                                   <&clk IMX8MN_SYS_PLL3>,
> >                                   <&clk IMX8MN_AUDIO_PLL1>,
> >                                   <&clk IMX8MN_AUDIO_PLL2>;
> >     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
> >                                              <&clk IMX8MN_ARM_PLL_OUT>,
> >                                              <&clk IMX8MN_SYS_PLL3_OUT>,
> >                                              <&clk IMX8MN_SYS_PLL1_800M>;
> >     assigned-clock-rates = <0>, <0>, <0>,
> >                                          <400000000>,
> >                                          <400000000>,
> >                                          <600000000>,
> >                                          <393216000>,
> >                                          <361267200>; };
> >
> > The spread spectrum is not configurable on these clocks or, more
> > generally, may not be configurable (only 4 PLLs have this capability).
> > Therefore, I need the "fsl,ssc-clocks"
> 
> No. That's not true. You do not need it.
> 

i.MX8M clock hardware is similar as:

OSC->ANATOP->CCM

ANATOP will produce PLLs.
CCM use PLLs as input source.

Currently there is no dedicated ANATOP driver in linux.
The CCM linux driver will parse the ANATOP node and
register clk_hw for the PLLs.


> First, the clock inputs for this device are listed in clocks *only*.
> What is no there, is not an input to the device. Including also Linux
> aspect (missing devlinks etc). Therefore how can you configure spread
> spectrum on clocks which are not connected to this device?

I not understand this well, you mean
add clocks = <xx CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?

Currently the CLK_IMX8MM_VIDEO_PLL is registers by CCM driver,
so impossible the add the upper clocks, unless a dedicated
anatop driver is developed.

Thanks
Peng.

> 
> Second, I do no ask you to configure spread spectrum on other clocks,
> only on the ones you intent to. List is fixed and ordered, so no problem
> with that.
> 
> > property to list the PLLs on which I want to enable and configure
> > spread spectrum.
> >
> > Furthermore, spread spectrum cannot be considered a new device
> but
> > rather a property available only for some of the clocks managed by
> the
> > clock controller manager (CCM).




> >
> 
> My comment stands and that's a disagreement from me. Feel free to
> get second DT maintainer opinion, though.
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Krzysztof Kozlowski]

On 08/11/2024 13:50, Peng Fan wrote:
>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
>> spread spectrum clocking
>>
>> On 07/11/2024 15:57, Dario Binacchi wrote:
>>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
>>>                   <&clk_ext3>, <&clk_ext4>;
>>>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
>>>                              "clk_ext3", "clk_ext4";
>>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
>>>                                   <&clk IMX8MN_CLK_A53_CORE>,
>>>                                   <&clk IMX8MN_CLK_NOC>,
>>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
>>>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
>>>                                   <&clk IMX8MN_SYS_PLL3>,
>>>                                   <&clk IMX8MN_AUDIO_PLL1>,
>>>                                   <&clk IMX8MN_AUDIO_PLL2>;
>>>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
>>>                                              <&clk IMX8MN_ARM_PLL_OUT>,
>>>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
>>>                                              <&clk IMX8MN_SYS_PLL1_800M>;
>>>     assigned-clock-rates = <0>, <0>, <0>,
>>>                                          <400000000>,
>>>                                          <400000000>,
>>>                                          <600000000>,
>>>                                          <393216000>,
>>>                                          <361267200>; };
>>>
>>> The spread spectrum is not configurable on these clocks or, more
>>> generally, may not be configurable (only 4 PLLs have this capability).
>>> Therefore, I need the "fsl,ssc-clocks"
>>
>> No. That's not true. You do not need it.
>>
> 
> i.MX8M clock hardware is similar as:
> 
> OSC->ANATOP->CCM
> 
> ANATOP will produce PLLs.
> CCM use PLLs as input source.
> 
> Currently there is no dedicated ANATOP driver in linux.
> The CCM linux driver will parse the ANATOP node and
> register clk_hw for the PLLs.

I do not know what is CCM and how does it fit here. What's more, I don't
get driver context here. We talk about bindings.


> 
> 
>> First, the clock inputs for this device are listed in clocks *only*.
>> What is no there, is not an input to the device. Including also Linux
>> aspect (missing devlinks etc). Therefore how can you configure spread
>> spectrum on clocks which are not connected to this device?
> 
> I not understand this well, you mean
> add clocks = <xx CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?

Yes. Let me re-iterate and please respond to this exactly comment
instead of ignoring it.

How a device can care about spread spectrum of a clock which is not
supplied to this device?

Why would you care about spread spectrum of some clock which is not
coming to this device?

Please address these precisely because we talk about this for weeks in
multiple places. I finish with this patchset if you do not provide such
context.

Best regards,
Krzysztof

RE: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Peng Fan]

> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
> spread spectrum clocking
> 
> On 08/11/2024 13:50, Peng Fan wrote:
> >> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> support
> >> spread spectrum clocking
> >>
> >> On 07/11/2024 15:57, Dario Binacchi wrote:
> >>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
> >>>                   <&clk_ext3>, <&clk_ext4>;
> >>>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
> >>>                              "clk_ext3", "clk_ext4";
> >>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
> >>>                                   <&clk IMX8MN_CLK_A53_CORE>,
> >>>                                   <&clk IMX8MN_CLK_NOC>,
> >>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
> >>>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
> >>>                                   <&clk IMX8MN_SYS_PLL3>,
> >>>                                   <&clk IMX8MN_AUDIO_PLL1>,
> >>>                                   <&clk IMX8MN_AUDIO_PLL2>;
> >>>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
> >>>                                              <&clk IMX8MN_ARM_PLL_OUT>,
> >>>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
> >>>                                              <&clk IMX8MN_SYS_PLL1_800M>;
> >>>     assigned-clock-rates = <0>, <0>, <0>,
> >>>                                          <400000000>,
> >>>                                          <400000000>,
> >>>                                          <600000000>,
> >>>                                          <393216000>,
> >>>                                          <361267200>; };
> >>>
> >>> The spread spectrum is not configurable on these clocks or, more
> >>> generally, may not be configurable (only 4 PLLs have this
> capability).
> >>> Therefore, I need the "fsl,ssc-clocks"
> >>
> >> No. That's not true. You do not need it.
> >>
> >
> > i.MX8M clock hardware is similar as:
> >
> > OSC->ANATOP->CCM
> >
> > ANATOP will produce PLLs.
> > CCM use PLLs as input source.
> >
> > Currently there is no dedicated ANATOP driver in linux.
> > The CCM linux driver will parse the ANATOP node and register clk_hw
> > for the PLLs.
> 
> I do not know what is CCM and how does it fit here. What's more, I
> don't get driver context here. We talk about bindings.


CCM: Clock Control Module, it accepts PLL from anatop as inputs,
and outputs clocks to various modules, I2C, CAN, NET, SAI and ...

> 
> 
> >
> >
> >> First, the clock inputs for this device are listed in clocks *only*.
> >> What is no there, is not an input to the device. Including also Linux
> >> aspect (missing devlinks etc). Therefore how can you configure
> spread
> >> spectrum on clocks which are not connected to this device?
> >
> > I not understand this well, you mean
> > add clocks = <xx CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?
> 
> Yes. Let me re-iterate and please respond to this exactly comment
> instead of ignoring it.
> 
> How a device can care about spread spectrum of a clock which is not
> supplied to this device?

I hope we are on same page of what spread spectrum means.
spread spectrum of a clock is the clock could produce freq in a range,
saying [500MHz - 100KHz, 500MHz + 100KHz]. software only need
to configure the middle frequency and choose the up/down border
range(100KHz here) and enable spread spectrum. 

device: I suppose you mean the Clock Control Module(CCM) here.
CCM does not care, it just accepts the PLL as input, and output
divided clock to various IPs(Video here). The video IPs care about
the spread spectrum of the clock.

The clock hardware path is as below:

OSC(24M) --> Anatop(produce PLL with spread spectrum) ->
Clock Control Module(output clock to modules) -> Video IP

From hardware perspective, Clock Control Module does not
care spread spectrum. Video IP cares spread spectrum.


> 
> Why would you care about spread spectrum of some clock which is not
> coming to this device?

device, I suppose you mean clock control module(CCM). 

There is no 'clocks = <&ccm CLK_IMX8M_VIDEO_PLL>' under ccm node.
Because in current design, ccm is taken as producer of
CLK_IMX8M_VIDEO_PLL, not consumer. 

> 
> Please address these precisely because we talk about this for weeks in
> multiple places. 

Sorry for coming into this feature in late stage.

Dario, thanks for working on such feature, good to see. Spread Spectrum
is indeed good feature what makes clock quality high.

Thanks,
Peng.

I finish with this patchset if you do not provide such
> context.
> 
> Best regards,
> Krzysztof

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Adam Ford]

On Fri, Nov 8, 2024 at 6:37 PM Peng Fan <peng.fan@nxp.com> wrote:
>
> > Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
> > spread spectrum clocking
> >
> > On 08/11/2024 13:50, Peng Fan wrote:
> > >> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> > support
> > >> spread spectrum clocking
> > >>
> > >> On 07/11/2024 15:57, Dario Binacchi wrote:
> > >>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
> > >>>                   <&clk_ext3>, <&clk_ext4>;
> > >>>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
> > >>>                              "clk_ext3", "clk_ext4";
> > >>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
> > >>>                                   <&clk IMX8MN_CLK_A53_CORE>,
> > >>>                                   <&clk IMX8MN_CLK_NOC>,
> > >>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
> > >>>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
> > >>>                                   <&clk IMX8MN_SYS_PLL3>,
> > >>>                                   <&clk IMX8MN_AUDIO_PLL1>,
> > >>>                                   <&clk IMX8MN_AUDIO_PLL2>;
> > >>>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
> > >>>                                              <&clk IMX8MN_ARM_PLL_OUT>,
> > >>>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
> > >>>                                              <&clk IMX8MN_SYS_PLL1_800M>;
> > >>>     assigned-clock-rates = <0>, <0>, <0>,
> > >>>                                          <400000000>,
> > >>>                                          <400000000>,
> > >>>                                          <600000000>,
> > >>>                                          <393216000>,
> > >>>                                          <361267200>; };
> > >>>
> > >>> The spread spectrum is not configurable on these clocks or, more
> > >>> generally, may not be configurable (only 4 PLLs have this
> > capability).
> > >>> Therefore, I need the "fsl,ssc-clocks"
> > >>
> > >> No. That's not true. You do not need it.
> > >>
> > >
> > > i.MX8M clock hardware is similar as:
> > >
> > > OSC->ANATOP->CCM
> > >
> > > ANATOP will produce PLLs.
> > > CCM use PLLs as input source.
> > >
> > > Currently there is no dedicated ANATOP driver in linux.
> > > The CCM linux driver will parse the ANATOP node and register clk_hw
> > > for the PLLs.
> >
> > I do not know what is CCM and how does it fit here. What's more, I
> > don't get driver context here. We talk about bindings.
>
>
> CCM: Clock Control Module, it accepts PLL from anatop as inputs,
> and outputs clocks to various modules, I2C, CAN, NET, SAI and ...
>
> >
> >
> > >
> > >
> > >> First, the clock inputs for this device are listed in clocks *only*.
> > >> What is no there, is not an input to the device. Including also Linux
> > >> aspect (missing devlinks etc). Therefore how can you configure
> > spread
> > >> spectrum on clocks which are not connected to this device?
> > >
> > > I not understand this well, you mean
> > > add clocks = <xx CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?
> >
> > Yes. Let me re-iterate and please respond to this exactly comment
> > instead of ignoring it.
> >
> > How a device can care about spread spectrum of a clock which is not
> > supplied to this device?
>
> I hope we are on same page of what spread spectrum means.
> spread spectrum of a clock is the clock could produce freq in a range,
> saying [500MHz - 100KHz, 500MHz + 100KHz]. software only need
> to configure the middle frequency and choose the up/down border
> range(100KHz here) and enable spread spectrum.
>
> device: I suppose you mean the Clock Control Module(CCM) here.
> CCM does not care, it just accepts the PLL as input, and output
> divided clock to various IPs(Video here). The video IPs care about
> the spread spectrum of the clock.
>
> The clock hardware path is as below:
>
> OSC(24M) --> Anatop(produce PLL with spread spectrum) ->
> Clock Control Module(output clock to modules) -> Video IP
>
> From hardware perspective, Clock Control Module does not
> care spread spectrum. Video IP cares spread spectrum.
>
>
> >
> > Why would you care about spread spectrum of some clock which is not
> > coming to this device?
>
> device, I suppose you mean clock control module(CCM).
>
> There is no 'clocks = <&ccm CLK_IMX8M_VIDEO_PLL>' under ccm node.
> Because in current design, ccm is taken as producer of
> CLK_IMX8M_VIDEO_PLL, not consumer.
>
> >
> > Please address these precisely because we talk about this for weeks in
> > multiple places.
>
> Sorry for coming into this feature in late stage.
>
> Dario, thanks for working on such feature, good to see. Spread Spectrum
> is indeed good feature what makes clock quality high.

I am also excited to see the spread-spectum clocks enabled.  We've
struggled with EMC testing in the past, and I want to reevaluate at
least one board with the spread-spectrum enabled to see how it
compares.
Thank you for working on this.

adam
>
> Thanks,
> Peng.
>
> I finish with this patchset if you do not provide such
> > context.
> >
> > Best regards,
> > Krzysztof
>

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Krzysztof Kozlowski]

On 09/11/2024 01:37, Peng Fan wrote:
>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
>> spread spectrum clocking
>>
>> On 08/11/2024 13:50, Peng Fan wrote:
>>>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
>> support
>>>> spread spectrum clocking
>>>>
>>>> On 07/11/2024 15:57, Dario Binacchi wrote:
>>>>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
>>>>>                   <&clk_ext3>, <&clk_ext4>;
>>>>>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
>>>>>                              "clk_ext3", "clk_ext4";
>>>>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
>>>>>                                   <&clk IMX8MN_CLK_A53_CORE>,
>>>>>                                   <&clk IMX8MN_CLK_NOC>,
>>>>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
>>>>>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
>>>>>                                   <&clk IMX8MN_SYS_PLL3>,
>>>>>                                   <&clk IMX8MN_AUDIO_PLL1>,
>>>>>                                   <&clk IMX8MN_AUDIO_PLL2>;
>>>>>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
>>>>>                                              <&clk IMX8MN_ARM_PLL_OUT>,
>>>>>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
>>>>>                                              <&clk IMX8MN_SYS_PLL1_800M>;
>>>>>     assigned-clock-rates = <0>, <0>, <0>,
>>>>>                                          <400000000>,
>>>>>                                          <400000000>,
>>>>>                                          <600000000>,
>>>>>                                          <393216000>,
>>>>>                                          <361267200>; };
>>>>>
>>>>> The spread spectrum is not configurable on these clocks or, more
>>>>> generally, may not be configurable (only 4 PLLs have this
>> capability).
>>>>> Therefore, I need the "fsl,ssc-clocks"
>>>>
>>>> No. That's not true. You do not need it.
>>>>
>>>
>>> i.MX8M clock hardware is similar as:
>>>
>>> OSC->ANATOP->CCM
>>>
>>> ANATOP will produce PLLs.
>>> CCM use PLLs as input source.
>>>
>>> Currently there is no dedicated ANATOP driver in linux.
>>> The CCM linux driver will parse the ANATOP node and register clk_hw
>>> for the PLLs.
>>
>> I do not know what is CCM and how does it fit here. What's more, I
>> don't get driver context here. We talk about bindings.
> 
> 
> CCM: Clock Control Module, it accepts PLL from anatop as inputs,
> and outputs clocks to various modules, I2C, CAN, NET, SAI and ...
> 
>>
>>
>>>
>>>
>>>> First, the clock inputs for this device are listed in clocks *only*.
>>>> What is no there, is not an input to the device. Including also Linux
>>>> aspect (missing devlinks etc). Therefore how can you configure
>> spread
>>>> spectrum on clocks which are not connected to this device?
>>>
>>> I not understand this well, you mean
>>> add clocks = <xx CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?
>>
>> Yes. Let me re-iterate and please respond to this exactly comment
>> instead of ignoring it.
>>
>> How a device can care about spread spectrum of a clock which is not
>> supplied to this device?
> 
> I hope we are on same page of what spread spectrum means.
> spread spectrum of a clock is the clock could produce freq in a range,
> saying [500MHz - 100KHz, 500MHz + 100KHz]. software only need
> to configure the middle frequency and choose the up/down border
> range(100KHz here) and enable spread spectrum. 
> 
> device: I suppose you mean the Clock Control Module(CCM) here.

I mean the device we discuss here, in this binding. Whatever this device
is. CCM or CCX

> CCM does not care, it just accepts the PLL as input, and output

Takes PLL as input but you refuse to add it as clocks? Are you really
responding to my question?

I asked how can you set spread spectrum on clock which you do not
receive. Why you do not receive? Because you refuse to add it to clocks
even though I speak about this since months.

> divided clock to various IPs(Video here). The video IPs care about
> the spread spectrum of the clock.

So which device do we talk about? I am not a NXP clock developer and I
care zero about NXP, so keep it simple. We discuss this one specific
binding for specific device which is called "imx8m-clock" - see subject
prefix.

> 
> The clock hardware path is as below:
> 
> OSC(24M) --> Anatop(produce PLL with spread spectrum) ->
> Clock Control Module(output clock to modules) -> Video IP
> 
> From hardware perspective, Clock Control Module does not
> care spread spectrum. Video IP cares spread spectrum.
> 
> 
>>
>> Why would you care about spread spectrum of some clock which is not
>> coming to this device?
> 
> device, I suppose you mean clock control module(CCM). 
> 
> There is no 'clocks = <&ccm CLK_IMX8M_VIDEO_PLL>' under ccm node.
> Because in current design, ccm is taken as producer of
> CLK_IMX8M_VIDEO_PLL, not consumer. 

I don't understand now even more. Or I understand even less now. Why
binding references its own clocks via phandle? This makes no sense at
all, except of course assigned clocks, but that's because we have one
property for multiple cases.


Best regards,
Krzysztof

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Krzysztof Kozlowski]

On 09/11/2024 11:05, Krzysztof Kozlowski wrote:
> On 09/11/2024 01:37, Peng Fan wrote:
>>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
>>> spread spectrum clocking
>>>
>>> On 08/11/2024 13:50, Peng Fan wrote:
>>>>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
>>> support
>>>>> spread spectrum clocking
>>>>>
>>>>> On 07/11/2024 15:57, Dario Binacchi wrote:
>>>>>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
>>>>>>                   <&clk_ext3>, <&clk_ext4>;
>>>>>>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
>>>>>>                              "clk_ext3", "clk_ext4";
>>>>>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
>>>>>>                                   <&clk IMX8MN_CLK_A53_CORE>,
>>>>>>                                   <&clk IMX8MN_CLK_NOC>,
>>>>>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
>>>>>>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
>>>>>>                                   <&clk IMX8MN_SYS_PLL3>,
>>>>>>                                   <&clk IMX8MN_AUDIO_PLL1>,
>>>>>>                                   <&clk IMX8MN_AUDIO_PLL2>;
>>>>>>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
>>>>>>                                              <&clk IMX8MN_ARM_PLL_OUT>,
>>>>>>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
>>>>>>                                              <&clk IMX8MN_SYS_PLL1_800M>;
>>>>>>     assigned-clock-rates = <0>, <0>, <0>,
>>>>>>                                          <400000000>,
>>>>>>                                          <400000000>,
>>>>>>                                          <600000000>,
>>>>>>                                          <393216000>,
>>>>>>                                          <361267200>; };
>>>>>>
>>>>>> The spread spectrum is not configurable on these clocks or, more
>>>>>> generally, may not be configurable (only 4 PLLs have this
>>> capability).
>>>>>> Therefore, I need the "fsl,ssc-clocks"
>>>>>
>>>>> No. That's not true. You do not need it.
>>>>>
>>>>
>>>> i.MX8M clock hardware is similar as:
>>>>
>>>> OSC->ANATOP->CCM
>>>>
>>>> ANATOP will produce PLLs.
>>>> CCM use PLLs as input source.
>>>>
>>>> Currently there is no dedicated ANATOP driver in linux.
>>>> The CCM linux driver will parse the ANATOP node and register clk_hw
>>>> for the PLLs.
>>>
>>> I do not know what is CCM and how does it fit here. What's more, I
>>> don't get driver context here. We talk about bindings.
>>
>>
>> CCM: Clock Control Module, it accepts PLL from anatop as inputs,
>> and outputs clocks to various modules, I2C, CAN, NET, SAI and ...
>>
>>>
>>>
>>>>
>>>>
>>>>> First, the clock inputs for this device are listed in clocks *only*.
>>>>> What is no there, is not an input to the device. Including also Linux
>>>>> aspect (missing devlinks etc). Therefore how can you configure
>>> spread
>>>>> spectrum on clocks which are not connected to this device?
>>>>
>>>> I not understand this well, you mean
>>>> add clocks = <xx CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?
>>>
>>> Yes. Let me re-iterate and please respond to this exactly comment
>>> instead of ignoring it.
>>>
>>> How a device can care about spread spectrum of a clock which is not
>>> supplied to this device?
>>
>> I hope we are on same page of what spread spectrum means.
>> spread spectrum of a clock is the clock could produce freq in a range,
>> saying [500MHz - 100KHz, 500MHz + 100KHz]. software only need
>> to configure the middle frequency and choose the up/down border
>> range(100KHz here) and enable spread spectrum. 
>>
>> device: I suppose you mean the Clock Control Module(CCM) here.
> 
> I mean the device we discuss here, in this binding. Whatever this device
> is. CCM or CCX
> 
>> CCM does not care, it just accepts the PLL as input, and output
> 
> Takes PLL as input but you refuse to add it as clocks? Are you really
> responding to my question?
> 
> I asked how can you set spread spectrum on clock which you do not
> receive. Why you do not receive? Because you refuse to add it to clocks
> even though I speak about this since months.
> 
>> divided clock to various IPs(Video here). The video IPs care about
>> the spread spectrum of the clock.
> 
> So which device do we talk about? I am not a NXP clock developer and I
> care zero about NXP, so keep it simple. We discuss this one specific
> binding for specific device which is called "imx8m-clock" - see subject
> prefix.
> 
>>
>> The clock hardware path is as below:
>>
>> OSC(24M) --> Anatop(produce PLL with spread spectrum) ->
>> Clock Control Module(output clock to modules) -> Video IP
>>
>> From hardware perspective, Clock Control Module does not
>> care spread spectrum. Video IP cares spread spectrum.
>>
>>
>>>
>>> Why would you care about spread spectrum of some clock which is not
>>> coming to this device?
>>
>> device, I suppose you mean clock control module(CCM). 
>>
>> There is no 'clocks = <&ccm CLK_IMX8M_VIDEO_PLL>' under ccm node.
>> Because in current design, ccm is taken as producer of
>> CLK_IMX8M_VIDEO_PLL, not consumer. 
> 
> I don't understand now even more. Or I understand even less now. Why
> binding references its own clocks via phandle? This makes no sense at
> all, except of course assigned clocks, but that's because we have one
> property for multiple cases.

And BTW if that was the point then the example is confusing because the
&clk phandle is not the device node in the example but it should.
Neither description says which device's clocks are these.

This is expressed very poorly in the binding, look:
"Phandles of the PLL" - it clearly suggests some other clocks, not its
own, that's so obvious I did not even think of asking. Patchset goes
slow also because of poor explanation, lack of diagrams and expecting me
to remember your clock hierarchy.

Best regards,
Krzysztof

RE: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Peng Fan]

> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
> spread spectrum clocking
> 
> On 09/11/2024 11:05, Krzysztof Kozlowski wrote:
> > On 09/11/2024 01:37, Peng Fan wrote:
> >>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> support
> >>> spread spectrum clocking
> >>>
> >>> On 08/11/2024 13:50, Peng Fan wrote:
> >>>>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> >>> support
> >>>>> spread spectrum clocking
> >>>>>
> >>>>> On 07/11/2024 15:57, Dario Binacchi wrote:
> >>>>>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>,
> <&clk_ext2>,
> >>>>>>                   <&clk_ext3>, <&clk_ext4>;
> >>>>>>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
> >>>>>>                              "clk_ext3", "clk_ext4";
> >>>>>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
> >>>>>>                                   <&clk IMX8MN_CLK_A53_CORE>,
> >>>>>>                                   <&clk IMX8MN_CLK_NOC>,
> >>>>>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
> >>>>>>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
> >>>>>>                                   <&clk IMX8MN_SYS_PLL3>,
> >>>>>>                                   <&clk IMX8MN_AUDIO_PLL1>,
> >>>>>>                                   <&clk IMX8MN_AUDIO_PLL2>;
> >>>>>>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
> >>>>>>                                              <&clk IMX8MN_ARM_PLL_OUT>,
> >>>>>>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
> >>>>>>                                              <&clk IMX8MN_SYS_PLL1_800M>;
> >>>>>>     assigned-clock-rates = <0>, <0>, <0>,
> >>>>>>                                          <400000000>,
> >>>>>>                                          <400000000>,
> >>>>>>                                          <600000000>,
> >>>>>>                                          <393216000>,
> >>>>>>                                          <361267200>; };
> >>>>>>
> >>>>>> The spread spectrum is not configurable on these clocks or,
> more
> >>>>>> generally, may not be configurable (only 4 PLLs have this
> >>> capability).
> >>>>>> Therefore, I need the "fsl,ssc-clocks"
> >>>>>
> >>>>> No. That's not true. You do not need it.
> >>>>>
> >>>>
> >>>> i.MX8M clock hardware is similar as:
> >>>>
> >>>> OSC->ANATOP->CCM
> >>>>
> >>>> ANATOP will produce PLLs.
> >>>> CCM use PLLs as input source.
> >>>>
> >>>> Currently there is no dedicated ANATOP driver in linux.
> >>>> The CCM linux driver will parse the ANATOP node and register
> clk_hw
> >>>> for the PLLs.
> >>>
> >>> I do not know what is CCM and how does it fit here. What's more, I
> >>> don't get driver context here. We talk about bindings.
> >>
> >>
> >> CCM: Clock Control Module, it accepts PLL from anatop as inputs,
> and
> >> outputs clocks to various modules, I2C, CAN, NET, SAI and ...
> >>
> >>>
> >>>
> >>>>
> >>>>
> >>>>> First, the clock inputs for this device are listed in clocks *only*.
> >>>>> What is no there, is not an input to the device. Including also
> >>>>> Linux aspect (missing devlinks etc). Therefore how can you
> >>>>> configure
> >>> spread
> >>>>> spectrum on clocks which are not connected to this device?
> >>>>
> >>>> I not understand this well, you mean add clocks = <xx
> >>>> CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?
> >>>
> >>> Yes. Let me re-iterate and please respond to this exactly comment
> >>> instead of ignoring it.
> >>>
> >>> How a device can care about spread spectrum of a clock which is
> not
> >>> supplied to this device?
> >>
> >> I hope we are on same page of what spread spectrum means.
> >> spread spectrum of a clock is the clock could produce freq in a
> >> range, saying [500MHz - 100KHz, 500MHz + 100KHz]. software only
> need
> >> to configure the middle frequency and choose the up/down border
> >> range(100KHz here) and enable spread spectrum.
> >>
> >> device: I suppose you mean the Clock Control Module(CCM) here.
> >
> > I mean the device we discuss here, in this binding. Whatever this
> > device is. CCM or CCX
> >
> >> CCM does not care, it just accepts the PLL as input, and output
> >
> > Takes PLL as input but you refuse to add it as clocks? Are you really
> > responding to my question?
> >
> > I asked how can you set spread spectrum on clock which you do not
> > receive. Why you do not receive? Because you refuse to add it to
> > clocks even though I speak about this since months.
> >
> >> divided clock to various IPs(Video here). The video IPs care about
> >> the spread spectrum of the clock.
> >
> > So which device do we talk about? I am not a NXP clock developer
> and I
> > care zero about NXP, so keep it simple. We discuss this one specific
> > binding for specific device which is called "imx8m-clock" - see
> > subject prefix.
> >
> >>
> >> The clock hardware path is as below:
> >>
> >> OSC(24M) --> Anatop(produce PLL with spread spectrum) -> Clock
> >> Control Module(output clock to modules) -> Video IP
> >>
> >> From hardware perspective, Clock Control Module does not care
> spread
> >> spectrum. Video IP cares spread spectrum.
> >>
> >>
> >>>
> >>> Why would you care about spread spectrum of some clock which is
> not
> >>> coming to this device?
> >>
> >> device, I suppose you mean clock control module(CCM).
> >>
> >> There is no 'clocks = <&ccm CLK_IMX8M_VIDEO_PLL>' under ccm
> node.
> >> Because in current design, ccm is taken as producer of
> >> CLK_IMX8M_VIDEO_PLL, not consumer.
> >
> > I don't understand now even more. Or I understand even less now.
> Why
> > binding references its own clocks via phandle? This makes no sense
> at
> > all, except of course assigned clocks, but that's because we have one
> > property for multiple cases.
> 
> And BTW if that was the point then the example is confusing because
> the &clk phandle is not the device node in the example but it should.
> Neither description says which device's clocks are these.
> 
> This is expressed very poorly in the binding, look:
> "Phandles of the PLL" - it clearly suggests some other clocks, not its
> own, that's so obvious I did not even think of asking. Patchset goes
> slow also because of poor explanation, lack of diagrams and expecting
> me to remember your clock hierarchy.


Dario may improve the patchset in new version. But let me just try
to explain a bit more about the hardware logic, I hope this could
give you some knowledge on i.MX clock and we could get some
suggestions on next:


OSC will generate 24MHz clock to Anatop module.
Anatop module takes 24MHz as input and produces various PLLs.
Clock Control Module(CCM) takes PLLs as input, and outputs the final
clocks to various IPs, saying video IPs.

The Anatop module could produce PLLs with spread spectrum enabled.
The Clock Control module just divides the freq and output the end IPs.
The end IPs cares about spread spectrum for high quality clock, the
Clock Control modules does not care. Now back to binding,

There is a imx8m-anatop binding fsl,imx8m-anatop.yaml for anatop
and a imx8m-clock.yaml binding for clock control module.

I think the patchset is to enable spread spectrum of a PLL globally,
not for a specific device saying video IP here. So the patchset put
the properties under the clock control module.

For example, there are VPU_JPEG, VPU_DECODE, both will use
video PLL with high quality. So the clock producer just produce
PLLs with Spread Spectrum(SS) enabled, and put the SS properties
under CCM or anatop node, not video IP nodes.


We could have a talk on IRC if Dario, Abel and you are available to
discuss on this topic.

Thanks,
Peng.

> 
> Best regards,
> Krzysztof

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Dario Binacchi]

On Mon, Nov 11, 2024 at 2:49 AM Peng Fan <peng.fan@nxp.com> wrote:
>
> > Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
> > spread spectrum clocking
> >
> > On 09/11/2024 11:05, Krzysztof Kozlowski wrote:
> > > On 09/11/2024 01:37, Peng Fan wrote:
> > >>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> > support
> > >>> spread spectrum clocking
> > >>>
> > >>> On 08/11/2024 13:50, Peng Fan wrote:
> > >>>>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> > >>> support
> > >>>>> spread spectrum clocking
> > >>>>>
> > >>>>> On 07/11/2024 15:57, Dario Binacchi wrote:
> > >>>>>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>,
> > <&clk_ext2>,
> > >>>>>>                   <&clk_ext3>, <&clk_ext4>;
> > >>>>>>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
> > >>>>>>                              "clk_ext3", "clk_ext4";
> > >>>>>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
> > >>>>>>                                   <&clk IMX8MN_CLK_A53_CORE>,
> > >>>>>>                                   <&clk IMX8MN_CLK_NOC>,
> > >>>>>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
> > >>>>>>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
> > >>>>>>                                   <&clk IMX8MN_SYS_PLL3>,
> > >>>>>>                                   <&clk IMX8MN_AUDIO_PLL1>,
> > >>>>>>                                   <&clk IMX8MN_AUDIO_PLL2>;
> > >>>>>>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
> > >>>>>>                                              <&clk IMX8MN_ARM_PLL_OUT>,
> > >>>>>>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
> > >>>>>>                                              <&clk IMX8MN_SYS_PLL1_800M>;
> > >>>>>>     assigned-clock-rates = <0>, <0>, <0>,
> > >>>>>>                                          <400000000>,
> > >>>>>>                                          <400000000>,
> > >>>>>>                                          <600000000>,
> > >>>>>>                                          <393216000>,
> > >>>>>>                                          <361267200>; };
> > >>>>>>
> > >>>>>> The spread spectrum is not configurable on these clocks or,
> > more
> > >>>>>> generally, may not be configurable (only 4 PLLs have this
> > >>> capability).
> > >>>>>> Therefore, I need the "fsl,ssc-clocks"
> > >>>>>
> > >>>>> No. That's not true. You do not need it.
> > >>>>>
> > >>>>
> > >>>> i.MX8M clock hardware is similar as:
> > >>>>
> > >>>> OSC->ANATOP->CCM
> > >>>>
> > >>>> ANATOP will produce PLLs.
> > >>>> CCM use PLLs as input source.
> > >>>>
> > >>>> Currently there is no dedicated ANATOP driver in linux.
> > >>>> The CCM linux driver will parse the ANATOP node and register
> > clk_hw
> > >>>> for the PLLs.
> > >>>
> > >>> I do not know what is CCM and how does it fit here. What's more, I
> > >>> don't get driver context here. We talk about bindings.
> > >>
> > >>
> > >> CCM: Clock Control Module, it accepts PLL from anatop as inputs,
> > and
> > >> outputs clocks to various modules, I2C, CAN, NET, SAI and ...
> > >>
> > >>>
> > >>>
> > >>>>
> > >>>>
> > >>>>> First, the clock inputs for this device are listed in clocks *only*.
> > >>>>> What is no there, is not an input to the device. Including also
> > >>>>> Linux aspect (missing devlinks etc). Therefore how can you
> > >>>>> configure
> > >>> spread
> > >>>>> spectrum on clocks which are not connected to this device?
> > >>>>
> > >>>> I not understand this well, you mean add clocks = <xx
> > >>>> CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?
> > >>>
> > >>> Yes. Let me re-iterate and please respond to this exactly comment
> > >>> instead of ignoring it.
> > >>>
> > >>> How a device can care about spread spectrum of a clock which is
> > not
> > >>> supplied to this device?
> > >>
> > >> I hope we are on same page of what spread spectrum means.
> > >> spread spectrum of a clock is the clock could produce freq in a
> > >> range, saying [500MHz - 100KHz, 500MHz + 100KHz]. software only
> > need
> > >> to configure the middle frequency and choose the up/down border
> > >> range(100KHz here) and enable spread spectrum.
> > >>
> > >> device: I suppose you mean the Clock Control Module(CCM) here.
> > >
> > > I mean the device we discuss here, in this binding. Whatever this
> > > device is. CCM or CCX
> > >
> > >> CCM does not care, it just accepts the PLL as input, and output
> > >
> > > Takes PLL as input but you refuse to add it as clocks? Are you really
> > > responding to my question?
> > >
> > > I asked how can you set spread spectrum on clock which you do not
> > > receive. Why you do not receive? Because you refuse to add it to
> > > clocks even though I speak about this since months.
> > >
> > >> divided clock to various IPs(Video here). The video IPs care about
> > >> the spread spectrum of the clock.
> > >
> > > So which device do we talk about? I am not a NXP clock developer
> > and I
> > > care zero about NXP, so keep it simple. We discuss this one specific
> > > binding for specific device which is called "imx8m-clock" - see
> > > subject prefix.
> > >
> > >>
> > >> The clock hardware path is as below:
> > >>
> > >> OSC(24M) --> Anatop(produce PLL with spread spectrum) -> Clock
> > >> Control Module(output clock to modules) -> Video IP
> > >>
> > >> From hardware perspective, Clock Control Module does not care
> > spread
> > >> spectrum. Video IP cares spread spectrum.
> > >>
> > >>
> > >>>
> > >>> Why would you care about spread spectrum of some clock which is
> > not
> > >>> coming to this device?
> > >>
> > >> device, I suppose you mean clock control module(CCM).
> > >>
> > >> There is no 'clocks = <&ccm CLK_IMX8M_VIDEO_PLL>' under ccm
> > node.
> > >> Because in current design, ccm is taken as producer of
> > >> CLK_IMX8M_VIDEO_PLL, not consumer.
> > >
> > > I don't understand now even more. Or I understand even less now.
> > Why
> > > binding references its own clocks via phandle? This makes no sense
> > at
> > > all, except of course assigned clocks, but that's because we have one
> > > property for multiple cases.
> >
> > And BTW if that was the point then the example is confusing because
> > the &clk phandle is not the device node in the example but it should.
> > Neither description says which device's clocks are these.
> >
> > This is expressed very poorly in the binding, look:
> > "Phandles of the PLL" - it clearly suggests some other clocks, not its
> > own, that's so obvious I did not even think of asking. Patchset goes
> > slow also because of poor explanation, lack of diagrams and expecting
> > me to remember your clock hierarchy.
>
>
> Dario may improve the patchset in new version. But let me just try
> to explain a bit more about the hardware logic, I hope this could
> give you some knowledge on i.MX clock and we could get some
> suggestions on next:
>
>
> OSC will generate 24MHz clock to Anatop module.
> Anatop module takes 24MHz as input and produces various PLLs.
> Clock Control Module(CCM) takes PLLs as input, and outputs the final
> clocks to various IPs, saying video IPs.
>
> The Anatop module could produce PLLs with spread spectrum enabled.
> The Clock Control module just divides the freq and output the end IPs.
> The end IPs cares about spread spectrum for high quality clock, the
> Clock Control modules does not care. Now back to binding,
>
> There is a imx8m-anatop binding fsl,imx8m-anatop.yaml for anatop
> and a imx8m-clock.yaml binding for clock control module.
>
> I think the patchset is to enable spread spectrum of a PLL globally,
> not for a specific device saying video IP here. So the patchset put
> the properties under the clock control module.
>
> For example, there are VPU_JPEG, VPU_DECODE, both will use
> video PLL with high quality. So the clock producer just produce
> PLLs with Spread Spectrum(SS) enabled, and put the SS properties
> under CCM or anatop node, not video IP nodes.

Thank you Peng, for the information.

Do you think it would make sense to add the PLL nodes with SSCG to the
anatop node?

anatop: clock-controller@30360000 {
    compatible = "fsl,imx8mn-anatop", "fsl,imx8mm-anatop";
    reg = <0x30360000 0x10000>;
    #clock-cells = <1>;

    clk_video_pll1_ref_sel: clock-video-pll1-ref-sel@28 {
        compatible = "fsl,imx8mn-mux-clock";
        #clock-cells = <0>;
        clocks = <&osc_24m>, <&clk_dummy>, <&clk_dummy>, <&clk_dummy>;
        fsl,anatop = <&anatop 0x28>;
        fsl,bit-shift = <0>;
        clock-output-names = "video_pll1_ref_sel";
    };

    clk_video_pll1: clock-video-pll1@28 {
        compatible = "fsl,pll14xx-clock";
        #clock-cells = <0>;
        clocks = <&clk_video_pll1_ref_sel>;
        ...
        fsl,ssc-modfreq-hz = <6000>;
        fsl,ssc-modrate-percent = <3>;
        fsl,ssc-modmethod = "down-spread";
    };
};

This example only considers the video PLL, so to be complete, it
should also add the clk_audio_pll1,
clk_audio_pll2 and clk_dram_pll nodes. It is based on an RFC series
that I sent about a year ago,
which was not accepted. In this way, the SSCG properties (i.e.,
"fsl,ssc-modfreq-hz", "fsl,ssc-modrate-percent"
and "fsl,ssc-modmethod") would be added to the relevant nodes, and I
would take only the essential parts
from that series. This would still mean implementing the PLL driver
("fsl,pll14xx-clock") and its mux ("fsl,imx8mn-mux-clock").

These clocks can then be added to the "clocks" list of the "ccm" node:

clk: clock-controller@30380000 {
    compatible = "fsl,imx8mn-ccm";
    ...
    clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
                  <&clk_ext3>, <&clk_ext4>, <&clk_video_pll1>,
                  <&clk_audio_pll1>, <&clk_audio_pll2>, <&clk_dram_pll>;
    ...
}

>
>
> We could have a talk on IRC if Dario, Abel and you are available to
> discuss on this topic.

Yes, I am available.

Thanks and regards,
Dario

>
> Thanks,
> Peng.
>
> >
> > Best regards,
> > Krzysztof
>


-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binacchi@amarulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info@amarulasolutions.com

www.amarulasolutions.com

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Dario Binacchi]

On Mon, Nov 11, 2024 at 12:57 PM Dario Binacchi
<dario.binacchi@amarulasolutions.com> wrote:
>
> On Mon, Nov 11, 2024 at 2:49 AM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > > Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
> > > spread spectrum clocking
> > >
> > > On 09/11/2024 11:05, Krzysztof Kozlowski wrote:
> > > > On 09/11/2024 01:37, Peng Fan wrote:
> > > >>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> > > support
> > > >>> spread spectrum clocking
> > > >>>
> > > >>> On 08/11/2024 13:50, Peng Fan wrote:
> > > >>>>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> > > >>> support
> > > >>>>> spread spectrum clocking
> > > >>>>>
> > > >>>>> On 07/11/2024 15:57, Dario Binacchi wrote:
> > > >>>>>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>,
> > > <&clk_ext2>,
> > > >>>>>>                   <&clk_ext3>, <&clk_ext4>;
> > > >>>>>>     clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
> > > >>>>>>                              "clk_ext3", "clk_ext4";
> > > >>>>>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
> > > >>>>>>                                   <&clk IMX8MN_CLK_A53_CORE>,
> > > >>>>>>                                   <&clk IMX8MN_CLK_NOC>,
> > > >>>>>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
> > > >>>>>>                                   <&clk IMX8MN_CLK_IPG_AUDIO_ROOT>,
> > > >>>>>>                                   <&clk IMX8MN_SYS_PLL3>,
> > > >>>>>>                                   <&clk IMX8MN_AUDIO_PLL1>,
> > > >>>>>>                                   <&clk IMX8MN_AUDIO_PLL2>;
> > > >>>>>>     assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_800M>,
> > > >>>>>>                                              <&clk IMX8MN_ARM_PLL_OUT>,
> > > >>>>>>                                              <&clk IMX8MN_SYS_PLL3_OUT>,
> > > >>>>>>                                              <&clk IMX8MN_SYS_PLL1_800M>;
> > > >>>>>>     assigned-clock-rates = <0>, <0>, <0>,
> > > >>>>>>                                          <400000000>,
> > > >>>>>>                                          <400000000>,
> > > >>>>>>                                          <600000000>,
> > > >>>>>>                                          <393216000>,
> > > >>>>>>                                          <361267200>; };
> > > >>>>>>
> > > >>>>>> The spread spectrum is not configurable on these clocks or,
> > > more
> > > >>>>>> generally, may not be configurable (only 4 PLLs have this
> > > >>> capability).
> > > >>>>>> Therefore, I need the "fsl,ssc-clocks"
> > > >>>>>
> > > >>>>> No. That's not true. You do not need it.
> > > >>>>>
> > > >>>>
> > > >>>> i.MX8M clock hardware is similar as:
> > > >>>>
> > > >>>> OSC->ANATOP->CCM
> > > >>>>
> > > >>>> ANATOP will produce PLLs.
> > > >>>> CCM use PLLs as input source.
> > > >>>>
> > > >>>> Currently there is no dedicated ANATOP driver in linux.
> > > >>>> The CCM linux driver will parse the ANATOP node and register
> > > clk_hw
> > > >>>> for the PLLs.
> > > >>>
> > > >>> I do not know what is CCM and how does it fit here. What's more, I
> > > >>> don't get driver context here. We talk about bindings.
> > > >>
> > > >>
> > > >> CCM: Clock Control Module, it accepts PLL from anatop as inputs,
> > > and
> > > >> outputs clocks to various modules, I2C, CAN, NET, SAI and ...
> > > >>
> > > >>>
> > > >>>
> > > >>>>
> > > >>>>
> > > >>>>> First, the clock inputs for this device are listed in clocks *only*.
> > > >>>>> What is no there, is not an input to the device. Including also
> > > >>>>> Linux aspect (missing devlinks etc). Therefore how can you
> > > >>>>> configure
> > > >>> spread
> > > >>>>> spectrum on clocks which are not connected to this device?
> > > >>>>
> > > >>>> I not understand this well, you mean add clocks = <xx
> > > >>>> CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?
> > > >>>
> > > >>> Yes. Let me re-iterate and please respond to this exactly comment
> > > >>> instead of ignoring it.
> > > >>>
> > > >>> How a device can care about spread spectrum of a clock which is
> > > not
> > > >>> supplied to this device?
> > > >>
> > > >> I hope we are on same page of what spread spectrum means.
> > > >> spread spectrum of a clock is the clock could produce freq in a
> > > >> range, saying [500MHz - 100KHz, 500MHz + 100KHz]. software only
> > > need
> > > >> to configure the middle frequency and choose the up/down border
> > > >> range(100KHz here) and enable spread spectrum.
> > > >>
> > > >> device: I suppose you mean the Clock Control Module(CCM) here.
> > > >
> > > > I mean the device we discuss here, in this binding. Whatever this
> > > > device is. CCM or CCX
> > > >
> > > >> CCM does not care, it just accepts the PLL as input, and output
> > > >
> > > > Takes PLL as input but you refuse to add it as clocks? Are you really
> > > > responding to my question?
> > > >
> > > > I asked how can you set spread spectrum on clock which you do not
> > > > receive. Why you do not receive? Because you refuse to add it to
> > > > clocks even though I speak about this since months.
> > > >
> > > >> divided clock to various IPs(Video here). The video IPs care about
> > > >> the spread spectrum of the clock.
> > > >
> > > > So which device do we talk about? I am not a NXP clock developer
> > > and I
> > > > care zero about NXP, so keep it simple. We discuss this one specific
> > > > binding for specific device which is called "imx8m-clock" - see
> > > > subject prefix.
> > > >
> > > >>
> > > >> The clock hardware path is as below:
> > > >>
> > > >> OSC(24M) --> Anatop(produce PLL with spread spectrum) -> Clock
> > > >> Control Module(output clock to modules) -> Video IP
> > > >>
> > > >> From hardware perspective, Clock Control Module does not care
> > > spread
> > > >> spectrum. Video IP cares spread spectrum.
> > > >>
> > > >>
> > > >>>
> > > >>> Why would you care about spread spectrum of some clock which is
> > > not
> > > >>> coming to this device?
> > > >>
> > > >> device, I suppose you mean clock control module(CCM).
> > > >>
> > > >> There is no 'clocks = <&ccm CLK_IMX8M_VIDEO_PLL>' under ccm
> > > node.
> > > >> Because in current design, ccm is taken as producer of
> > > >> CLK_IMX8M_VIDEO_PLL, not consumer.
> > > >
> > > > I don't understand now even more. Or I understand even less now.
> > > Why
> > > > binding references its own clocks via phandle? This makes no sense
> > > at
> > > > all, except of course assigned clocks, but that's because we have one
> > > > property for multiple cases.
> > >
> > > And BTW if that was the point then the example is confusing because
> > > the &clk phandle is not the device node in the example but it should.
> > > Neither description says which device's clocks are these.
> > >
> > > This is expressed very poorly in the binding, look:
> > > "Phandles of the PLL" - it clearly suggests some other clocks, not its
> > > own, that's so obvious I did not even think of asking. Patchset goes
> > > slow also because of poor explanation, lack of diagrams and expecting
> > > me to remember your clock hierarchy.
> >
> >
> > Dario may improve the patchset in new version. But let me just try
> > to explain a bit more about the hardware logic, I hope this could
> > give you some knowledge on i.MX clock and we could get some
> > suggestions on next:
> >
> >
> > OSC will generate 24MHz clock to Anatop module.
> > Anatop module takes 24MHz as input and produces various PLLs.
> > Clock Control Module(CCM) takes PLLs as input, and outputs the final
> > clocks to various IPs, saying video IPs.
> >
> > The Anatop module could produce PLLs with spread spectrum enabled.
> > The Clock Control module just divides the freq and output the end IPs.
> > The end IPs cares about spread spectrum for high quality clock, the
> > Clock Control modules does not care. Now back to binding,
> >
> > There is a imx8m-anatop binding fsl,imx8m-anatop.yaml for anatop
> > and a imx8m-clock.yaml binding for clock control module.
> >
> > I think the patchset is to enable spread spectrum of a PLL globally,
> > not for a specific device saying video IP here. So the patchset put
> > the properties under the clock control module.
> >
> > For example, there are VPU_JPEG, VPU_DECODE, both will use
> > video PLL with high quality. So the clock producer just produce
> > PLLs with Spread Spectrum(SS) enabled, and put the SS properties
> > under CCM or anatop node, not video IP nodes.
>
> Thank you Peng, for the information.
>
> Do you think it would make sense to add the PLL nodes with SSCG to the
> anatop node?
>
> anatop: clock-controller@30360000 {
>     compatible = "fsl,imx8mn-anatop", "fsl,imx8mm-anatop";
>     reg = <0x30360000 0x10000>;
>     #clock-cells = <1>;
>
>     clk_video_pll1_ref_sel: clock-video-pll1-ref-sel@28 {
>         compatible = "fsl,imx8mn-mux-clock";
>         #clock-cells = <0>;
>         clocks = <&osc_24m>, <&clk_dummy>, <&clk_dummy>, <&clk_dummy>;
>         fsl,anatop = <&anatop 0x28>;
>         fsl,bit-shift = <0>;
>         clock-output-names = "video_pll1_ref_sel";
>     };
>
>     clk_video_pll1: clock-video-pll1@28 {
>         compatible = "fsl,pll14xx-clock";
>         #clock-cells = <0>;
>         clocks = <&clk_video_pll1_ref_sel>;
>         ...
>         fsl,ssc-modfreq-hz = <6000>;
>         fsl,ssc-modrate-percent = <3>;
>         fsl,ssc-modmethod = "down-spread";
>     };
> };
>
> This example only considers the video PLL, so to be complete, it
> should also add the clk_audio_pll1,
> clk_audio_pll2 and clk_dram_pll nodes. It is based on an RFC series
> that I sent about a year ago,
> which was not accepted. In this way, the SSCG properties (i.e.,
> "fsl,ssc-modfreq-hz", "fsl,ssc-modrate-percent"
> and "fsl,ssc-modmethod") would be added to the relevant nodes, and I
> would take only the essential parts
> from that series. This would still mean implementing the PLL driver
> ("fsl,pll14xx-clock") and its mux ("fsl,imx8mn-mux-clock").
>
> These clocks can then be added to the "clocks" list of the "ccm" node:
>
> clk: clock-controller@30380000 {
>     compatible = "fsl,imx8mn-ccm";
>     ...
>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
>                   <&clk_ext3>, <&clk_ext4>, <&clk_video_pll1>,
>                   <&clk_audio_pll1>, <&clk_audio_pll2>, <&clk_dram_pll>;
>     ...
> }
>
> >
> >

Next the series I forgot to reference in the previous email:
https://lore.kernel.org/lkml/20230101175740.1010258-1-dario.binacchi@amarulasolutions.com/

Thanks and regards,
Dario

> > We could have a talk on IRC if Dario, Abel and you are available to
> > discuss on this topic.
>
> Yes, I am available.
>
> Thanks and regards,
> Dario
>
> >
> > Thanks,
> > Peng.
> >
> > >
> > > Best regards,
> > > Krzysztof
> >
>
>
> --
>
> Dario Binacchi
>
> Senior Embedded Linux Developer
>
> dario.binacchi@amarulasolutions.com
>
> __________________________________
>
>
> Amarula Solutions SRL
>
> Via Le Canevare 30, 31100 Treviso, Veneto, IT
>
> T. +39 042 243 5310
> info@amarulasolutions.com
>
> www.amarulasolutions.com



-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binacchi@amarulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info@amarulasolutions.com

www.amarulasolutions.com

RE: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Peng Fan]

> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
> spread spectrum clocking
> 
> On Mon, Nov 11, 2024 at 12:57 PM Dario Binacchi
> <dario.binacchi@amarulasolutions.com> wrote:
> >
> > On Mon, Nov 11, 2024 at 2:49 AM Peng Fan <peng.fan@nxp.com>
> wrote:
> > >
> > > > Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> > > > support spread spectrum clocking
> > > >
> > > > On 09/11/2024 11:05, Krzysztof Kozlowski wrote:
> > > > > On 09/11/2024 01:37, Peng Fan wrote:
> > > > >>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock:
> > > > support
> > > > >>> spread spectrum clocking
> > > > >>>
> > > > >>> On 08/11/2024 13:50, Peng Fan wrote:
> > > > >>>>> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-
> clock:
> > > > >>> support
> > > > >>>>> spread spectrum clocking
> > > > >>>>>
> > > > >>>>> On 07/11/2024 15:57, Dario Binacchi wrote:
> > > > >>>>>>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>,
> > > > <&clk_ext2>,
> > > > >>>>>>                   <&clk_ext3>, <&clk_ext4>;
> > > > >>>>>>     clock-names = "osc_32k", "osc_24m", "clk_ext1",
> "clk_ext2",
> > > > >>>>>>                              "clk_ext3", "clk_ext4";
> > > > >>>>>>     assigned-clocks = <&clk IMX8MN_CLK_A53_SRC>,
> > > > >>>>>>                                   <&clk IMX8MN_CLK_A53_CORE>,
> > > > >>>>>>                                   <&clk IMX8MN_CLK_NOC>,
> > > > >>>>>>                                   <&clk IMX8MN_CLK_AUDIO_AHB>,
> > > > >>>>>>                                   <&clk
> IMX8MN_CLK_IPG_AUDIO_ROOT>,
> > > > >>>>>>                                   <&clk IMX8MN_SYS_PLL3>,
> > > > >>>>>>                                   <&clk IMX8MN_AUDIO_PLL1>,
> > > > >>>>>>                                   <&clk IMX8MN_AUDIO_PLL2>;
> > > > >>>>>>     assigned-clock-parents = <&clk
> IMX8MN_SYS_PLL1_800M>,
> > > > >>>>>>                                              <&clk
> IMX8MN_ARM_PLL_OUT>,
> > > > >>>>>>                                              <&clk
> IMX8MN_SYS_PLL3_OUT>,
> > > > >>>>>>                                              <&clk
> IMX8MN_SYS_PLL1_800M>;
> > > > >>>>>>     assigned-clock-rates = <0>, <0>, <0>,
> > > > >>>>>>                                          <400000000>,
> > > > >>>>>>                                          <400000000>,
> > > > >>>>>>                                          <600000000>,
> > > > >>>>>>                                          <393216000>,
> > > > >>>>>>                                          <361267200>; };
> > > > >>>>>>
> > > > >>>>>> The spread spectrum is not configurable on these clocks or,
> > > > more
> > > > >>>>>> generally, may not be configurable (only 4 PLLs have this
> > > > >>> capability).
> > > > >>>>>> Therefore, I need the "fsl,ssc-clocks"
> > > > >>>>>
> > > > >>>>> No. That's not true. You do not need it.
> > > > >>>>>
> > > > >>>>
> > > > >>>> i.MX8M clock hardware is similar as:
> > > > >>>>
> > > > >>>> OSC->ANATOP->CCM
> > > > >>>>
> > > > >>>> ANATOP will produce PLLs.
> > > > >>>> CCM use PLLs as input source.
> > > > >>>>
> > > > >>>> Currently there is no dedicated ANATOP driver in linux.
> > > > >>>> The CCM linux driver will parse the ANATOP node and
> register
> > > > clk_hw
> > > > >>>> for the PLLs.
> > > > >>>
> > > > >>> I do not know what is CCM and how does it fit here. What's
> > > > >>> more, I don't get driver context here. We talk about bindings.
> > > > >>
> > > > >>
> > > > >> CCM: Clock Control Module, it accepts PLL from anatop as
> > > > >> inputs,
> > > > and
> > > > >> outputs clocks to various modules, I2C, CAN, NET, SAI and ...
> > > > >>
> > > > >>>
> > > > >>>
> > > > >>>>
> > > > >>>>
> > > > >>>>> First, the clock inputs for this device are listed in clocks
> *only*.
> > > > >>>>> What is no there, is not an input to the device. Including
> > > > >>>>> also Linux aspect (missing devlinks etc). Therefore how can
> > > > >>>>> you configure
> > > > >>> spread
> > > > >>>>> spectrum on clocks which are not connected to this device?
> > > > >>>>
> > > > >>>> I not understand this well, you mean add clocks = <xx
> > > > >>>> CLK_IMX8MM_VIDEO_PLL> in the ccm dtb node?
> > > > >>>
> > > > >>> Yes. Let me re-iterate and please respond to this exactly
> > > > >>> comment instead of ignoring it.
> > > > >>>
> > > > >>> How a device can care about spread spectrum of a clock
> which
> > > > >>> is
> > > > not
> > > > >>> supplied to this device?
> > > > >>
> > > > >> I hope we are on same page of what spread spectrum means.
> > > > >> spread spectrum of a clock is the clock could produce freq in a
> > > > >> range, saying [500MHz - 100KHz, 500MHz + 100KHz]. software
> only
> > > > need
> > > > >> to configure the middle frequency and choose the up/down
> border
> > > > >> range(100KHz here) and enable spread spectrum.
> > > > >>
> > > > >> device: I suppose you mean the Clock Control Module(CCM)
> here.
> > > > >
> > > > > I mean the device we discuss here, in this binding. Whatever
> > > > > this device is. CCM or CCX
> > > > >
> > > > >> CCM does not care, it just accepts the PLL as input, and output
> > > > >
> > > > > Takes PLL as input but you refuse to add it as clocks? Are you
> > > > > really responding to my question?
> > > > >
> > > > > I asked how can you set spread spectrum on clock which you do
> > > > > not receive. Why you do not receive? Because you refuse to add
> > > > > it to clocks even though I speak about this since months.
> > > > >
> > > > >> divided clock to various IPs(Video here). The video IPs care
> > > > >> about the spread spectrum of the clock.
> > > > >
> > > > > So which device do we talk about? I am not a NXP clock
> developer
> > > > and I
> > > > > care zero about NXP, so keep it simple. We discuss this one
> > > > > specific binding for specific device which is called
> > > > > "imx8m-clock" - see subject prefix.
> > > > >
> > > > >>
> > > > >> The clock hardware path is as below:
> > > > >>
> > > > >> OSC(24M) --> Anatop(produce PLL with spread spectrum) ->
> Clock
> > > > >> Control Module(output clock to modules) -> Video IP
> > > > >>
> > > > >> From hardware perspective, Clock Control Module does not
> care
> > > > spread
> > > > >> spectrum. Video IP cares spread spectrum.
> > > > >>
> > > > >>
> > > > >>>
> > > > >>> Why would you care about spread spectrum of some clock
> which
> > > > >>> is
> > > > not
> > > > >>> coming to this device?
> > > > >>
> > > > >> device, I suppose you mean clock control module(CCM).
> > > > >>
> > > > >> There is no 'clocks = <&ccm CLK_IMX8M_VIDEO_PLL>' under
> ccm
> > > > node.
> > > > >> Because in current design, ccm is taken as producer of
> > > > >> CLK_IMX8M_VIDEO_PLL, not consumer.
> > > > >
> > > > > I don't understand now even more. Or I understand even less
> now.
> > > > Why
> > > > > binding references its own clocks via phandle? This makes no
> > > > > sense
> > > > at
> > > > > all, except of course assigned clocks, but that's because we
> > > > > have one property for multiple cases.
> > > >
> > > > And BTW if that was the point then the example is confusing
> > > > because the &clk phandle is not the device node in the example
> but it should.
> > > > Neither description says which device's clocks are these.
> > > >
> > > > This is expressed very poorly in the binding, look:
> > > > "Phandles of the PLL" - it clearly suggests some other clocks, not
> > > > its own, that's so obvious I did not even think of asking.
> > > > Patchset goes slow also because of poor explanation, lack of
> > > > diagrams and expecting me to remember your clock hierarchy.
> > >
> > >
> > > Dario may improve the patchset in new version. But let me just try
> > > to explain a bit more about the hardware logic, I hope this could
> > > give you some knowledge on i.MX clock and we could get some
> > > suggestions on next:
> > >
> > >
> > > OSC will generate 24MHz clock to Anatop module.
> > > Anatop module takes 24MHz as input and produces various PLLs.
> > > Clock Control Module(CCM) takes PLLs as input, and outputs the
> final
> > > clocks to various IPs, saying video IPs.
> > >
> > > The Anatop module could produce PLLs with spread spectrum
> enabled.
> > > The Clock Control module just divides the freq and output the end
> IPs.
> > > The end IPs cares about spread spectrum for high quality clock, the
> > > Clock Control modules does not care. Now back to binding,
> > >
> > > There is a imx8m-anatop binding fsl,imx8m-anatop.yaml for anatop
> and
> > > a imx8m-clock.yaml binding for clock control module.
> > >
> > > I think the patchset is to enable spread spectrum of a PLL globally,
> > > not for a specific device saying video IP here. So the patchset put
> > > the properties under the clock control module.
> > >
> > > For example, there are VPU_JPEG, VPU_DECODE, both will use
> video PLL
> > > with high quality. So the clock producer just produce PLLs with
> > > Spread Spectrum(SS) enabled, and put the SS properties under CCM
> or
> > > anatop node, not video IP nodes.
> >
> > Thank you Peng, for the information.
> >
> > Do you think it would make sense to add the PLL nodes with SSCG to
> the
> > anatop node?

I not know Krzysztof's view on what he expects on spread spectrum of
a clock. I just think we are not on same page, but not know where
we misunderstands, or I am wrong.

For your below dt, I think clock maintainer would not agree.

So my idea is
Using clocks to replace fsl,ssc-clocks is possible under
ccm mode, but you need to develop the
fsl,imx8mm-anatop clock driver.

Or just replace fsl,ssc-clocks with clock id under anatop node,
no phandle under anatop node.
Then let ccm driver to handle it.

Regards,
Peng.

> >
> > anatop: clock-controller@30360000 {
> >     compatible = "fsl,imx8mn-anatop", "fsl,imx8mm-anatop";
> >     reg = <0x30360000 0x10000>;
> >     #clock-cells = <1>;
> >
> >     clk_video_pll1_ref_sel: clock-video-pll1-ref-sel@28 {
> >         compatible = "fsl,imx8mn-mux-clock";
> >         #clock-cells = <0>;
> >         clocks = <&osc_24m>, <&clk_dummy>, <&clk_dummy>,
> <&clk_dummy>;
> >         fsl,anatop = <&anatop 0x28>;
> >         fsl,bit-shift = <0>;
> >         clock-output-names = "video_pll1_ref_sel";
> >     };
> >
> >     clk_video_pll1: clock-video-pll1@28 {
> >         compatible = "fsl,pll14xx-clock";
> >         #clock-cells = <0>;
> >         clocks = <&clk_video_pll1_ref_sel>;
> >         ...
> >         fsl,ssc-modfreq-hz = <6000>;
> >         fsl,ssc-modrate-percent = <3>;
> >         fsl,ssc-modmethod = "down-spread";
> >     };
> > };
> >
> > This example only considers the video PLL, so to be complete, it
> > should also add the clk_audio_pll1,
> > clk_audio_pll2 and clk_dram_pll nodes. It is based on an RFC series
> > that I sent about a year ago, which was not accepted. In this way, the
> > SSCG properties (i.e., "fsl,ssc-modfreq-hz", "fsl,ssc-modrate-percent"
> > and "fsl,ssc-modmethod") would be added to the relevant nodes, and
> I
> > would take only the essential parts from that series. This would still
> > mean implementing the PLL driver
> > ("fsl,pll14xx-clock") and its mux ("fsl,imx8mn-mux-clock").
> >
> > These clocks can then be added to the "clocks" list of the "ccm" node:
> >
> > clk: clock-controller@30380000 {
> >     compatible = "fsl,imx8mn-ccm";
> >     ...
> >     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
> >                   <&clk_ext3>, <&clk_ext4>, <&clk_video_pll1>,
> >                   <&clk_audio_pll1>, <&clk_audio_pll2>, <&clk_dram_pll>;
> >     ...
> > }
> >
> > >
> > >
> 
> Next the series I forgot to reference in the previous email:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> lore.kernel.org%2Flkml%2F20230101175740.1010258-1-
> dario.binacchi%40amarulasolutions.com%2F&data=05%7C02%7Cpeng.
> fan%40nxp.com%7C47c26bb6c16549ff778d08dd0257261d%7C686ea
> 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63866929551955069
> 0%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C0%7C%7C%7C&sdata=1uWbb%2Fxa4PjemrEpSFbsBQP2X466i2c
> jYaxjQKl1xfE%3D&reserved=0
> 
> Thanks and regards,
> Dario
> 
> > > We could have a talk on IRC if Dario, Abel and you are available to
> > > discuss on this topic.
> >
> > Yes, I am available.
> >
> > Thanks and regards,
> > Dario
> >
> > >
> > > Thanks,
> > > Peng.
> > >
> > > >
> > > > Best regards,
> > > > Krzysztof
> > >
> >
> >
> > --
> >
> > Dario Binacchi
> >
> > Senior Embedded Linux Developer
> >
> > dario.binacchi@amarulasolutions.com
> >
> > __________________________________
> >
> >
> > Amarula Solutions SRL
> >
> > Via Le Canevare 30, 31100 Treviso, Veneto, IT
> >
> > T. +39 042 243 5310
> > info@amarulasolutions.com
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> www.a
> >
> marulasolutions.com%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7
> C47c26bb6c16
> >
> 549ff778d08dd0257261d%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%7C638
> >
> 669295519581821%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> kiOnRydWUsIlYiOi
> >
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3
> D%7C0%7C%
> >
> 7C%7C&sdata=tK%2B9QB7Ri3eXJI%2FdXmCbwr%2BDwzdLt51CPo0DB
> pd%2BqOw%3D&res
> > erved=0
> 
> 
> 
> --
> 
> Dario Binacchi
> 
> Senior Embedded Linux Developer
> 
> dario.binacchi@amarulasolutions.com
> 
> __________________________________
> 
> 
> Amarula Solutions SRL
> 
> Via Le Canevare 30, 31100 Treviso, Veneto, IT
> 
> T. +39 042 243 5310
> info@amarulasolutions.com
> 
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> www.amarulasolutions.com%2F&data=05%7C02%7Cpeng.fan%40nxp.
> com%7C47c26bb6c16549ff778d08dd0257261d%7C686ea1d3bc2b4c6
> fa92cd99c5c301635%7C0%7C0%7C638669295519598876%7CUnkno
> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%7C&sdata=ypZC9LExvvra%2BPcQIOE8HHnuRs3fmHjMVvRpox7Vd
> AU%3D&reserved=0

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Krzysztof Kozlowski]

On 11/11/2024 12:57, Dario Binacchi wrote:
> 
> Thank you Peng, for the information.
> 
> Do you think it would make sense to add the PLL nodes with SSCG to the
> anatop node?
> 
> anatop: clock-controller@30360000 {
>     compatible = "fsl,imx8mn-anatop", "fsl,imx8mm-anatop";
>     reg = <0x30360000 0x10000>;
>     #clock-cells = <1>;
> 
>     clk_video_pll1_ref_sel: clock-video-pll1-ref-sel@28 {
>         compatible = "fsl,imx8mn-mux-clock";

No. Nodes per clock were long time ago NAKed.

>         #clock-cells = <0>;
>         clocks = <&osc_24m>, <&clk_dummy>, <&clk_dummy>, <&clk_dummy>;
>         fsl,anatop = <&anatop 0x28>;
>         fsl,bit-shift = <0>;
>         clock-output-names = "video_pll1_ref_sel";
>     };
> 
>     clk_video_pll1: clock-video-pll1@28 {
>         compatible = "fsl,pll14xx-clock";
>         #clock-cells = <0>;
>         clocks = <&clk_video_pll1_ref_sel>;
>         ...
>         fsl,ssc-modfreq-hz = <6000>;
>         fsl,ssc-modrate-percent = <3>;
>         fsl,ssc-modmethod = "down-spread";
>     };
> };
> 
> This example only considers the video PLL, so to be complete, it
> should also add the clk_audio_pll1,
> clk_audio_pll2 and clk_dram_pll nodes. It is based on an RFC series
> that I sent about a year ago,
> which was not accepted. In this way, the SSCG properties (i.e.,
> "fsl,ssc-modfreq-hz", "fsl,ssc-modrate-percent"
> and "fsl,ssc-modmethod") would be added to the relevant nodes, and I
> would take only the essential parts
> from that series. This would still mean implementing the PLL driver
> ("fsl,pll14xx-clock") and its mux ("fsl,imx8mn-mux-clock").
> 
> These clocks can then be added to the "clocks" list of the "ccm" node:
> 
> clk: clock-controller@30380000 {
>     compatible = "fsl,imx8mn-ccm";
>     ...
>     clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
>                   <&clk_ext3>, <&clk_ext4>, <&clk_video_pll1>,
>                   <&clk_audio_pll1>, <&clk_audio_pll2>, <&clk_dram_pll>;
>     ...
> }
> 
These clocks can be added anyway.

Best regards,
Krzysztof

Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Krzysztof Kozlowski]

On 11/11/2024 02:49, Peng Fan wrote:
>>> I don't understand now even more. Or I understand even less now.
>> Why
>>> binding references its own clocks via phandle? This makes no sense
>> at
>>> all, except of course assigned clocks, but that's because we have one
>>> property for multiple cases.
>>
>> And BTW if that was the point then the example is confusing because
>> the &clk phandle is not the device node in the example but it should.
>> Neither description says which device's clocks are these.
>>
>> This is expressed very poorly in the binding, look:
>> "Phandles of the PLL" - it clearly suggests some other clocks, not its
>> own, that's so obvious I did not even think of asking. Patchset goes
>> slow also because of poor explanation, lack of diagrams and expecting
>> me to remember your clock hierarchy.
> 
> 
> Dario may improve the patchset in new version. But let me just try
> to explain a bit more about the hardware logic, I hope this could
> give you some knowledge on i.MX clock and we could get some
> suggestions on next:
> 
> 
> OSC will generate 24MHz clock to Anatop module.
> Anatop module takes 24MHz as input and produces various PLLs.
> Clock Control Module(CCM) takes PLLs as input, and outputs the final
> clocks to various IPs, saying video IPs.
> 
> The Anatop module could produce PLLs with spread spectrum enabled.
> The Clock Control module just divides the freq and output the end IPs.
> The end IPs cares about spread spectrum for high quality clock, the
> Clock Control modules does not care. Now back to binding,

All above makes sense. The previous message:
"Because in current design, ccm is taken as producer of
CLK_IMX8M_VIDEO_PLL, not consumer. "

confused me a lot because it suggests that these PLLs are provided by
CCM. It turns out not... so the answer is like I said long time ago: you
must take these clocks as inputs and this is done via clocks property.
Not fsl,clocks or fsc,i-want-more-properties-clocks.

> 
> There is a imx8m-anatop binding fsl,imx8m-anatop.yaml for anatop
> and a imx8m-clock.yaml binding for clock control module.
> 
> I think the patchset is to enable spread spectrum of a PLL globally,
> not for a specific device saying video IP here. So the patchset put
> the properties under the clock control module.

I understand. This looks however as misrepresentation. If you do not
have the video IP block enabled, why would you configure spread
spectrum? IOW, spread spectrum as you described is needed for the final
IP block and this final IP block should configure it. Properties belong
there.

It's kind of similar for some OPP/performance/bandwidth requests. Even
more similar to clock frequencies. Which device requests to configure
given clock frequencies? Final consumer, not clock controller.


> 
> For example, there are VPU_JPEG, VPU_DECODE, both will use
> video PLL with high quality. So the clock producer just produce
> PLLs with Spread Spectrum(SS) enabled, and put the SS properties
> under CCM or anatop node, not video IP nodes.
> 
> 
> We could have a talk on IRC if Dario, Abel and you are available to
> discuss on this topic.



Best regards,
Krzysztof

RE: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support spread spectrum clocking

[Peng Fan]

> Subject: Re: [PATCH v3 1/8] dt-bindings: clock: imx8m-clock: support
> spread spectrum clocking
> 
> On 11/11/2024 02:49, Peng Fan wrote:
> >>> I don't understand now even more. Or I understand even less now.
> >> Why
> >>> binding references its own clocks via phandle? This makes no sense
> >> at
> >>> all, except of course assigned clocks, but that's because we have
> >>> one property for multiple cases.
> >>
> >> And BTW if that was the point then the example is confusing
> because
> >> the &clk phandle is not the device node in the example but it should.
> >> Neither description says which device's clocks are these.
> >>
> >> This is expressed very poorly in the binding, look:
> >> "Phandles of the PLL" - it clearly suggests some other clocks, not
> >> its own, that's so obvious I did not even think of asking. Patchset
> >> goes slow also because of poor explanation, lack of diagrams and
> >> expecting me to remember your clock hierarchy.
> >
> >
> > Dario may improve the patchset in new version. But let me just try to
> > explain a bit more about the hardware logic, I hope this could give
> > you some knowledge on i.MX clock and we could get some
> suggestions on
> > next:
> >
> >
> > OSC will generate 24MHz clock to Anatop module.
> > Anatop module takes 24MHz as input and produces various PLLs.
> > Clock Control Module(CCM) takes PLLs as input, and outputs the final
> > clocks to various IPs, saying video IPs.
> >
> > The Anatop module could produce PLLs with spread spectrum
> enabled.
> > The Clock Control module just divides the freq and output the end IPs.
> > The end IPs cares about spread spectrum for high quality clock, the
> > Clock Control modules does not care. Now back to binding,
> 
> All above makes sense. The previous message:
> "Because in current design, ccm is taken as producer of
> CLK_IMX8M_VIDEO_PLL, not consumer. "
> 
> confused me a lot because it suggests that these PLLs are provided by
> CCM. It turns out not... so the answer is like I said long time ago: you
> must take these clocks as inputs and this is done via clocks property.
> Not fsl,clocks or fsc,i-want-more-properties-clocks.
> 
> >
> > There is a imx8m-anatop binding fsl,imx8m-anatop.yaml for anatop
> and a
> > imx8m-clock.yaml binding for clock control module.
> >
> > I think the patchset is to enable spread spectrum of a PLL globally,
> > not for a specific device saying video IP here. So the patchset put
> > the properties under the clock control module.
> 
> I understand. This looks however as misrepresentation. If you do not
> have the video IP block enabled, why would you configure spread
> spectrum? IOW, spread spectrum as you described is needed for the
> final IP block and this final IP block should configure it. Properties
> belong there.

Multiple IPs use same PLLs as source and share same pll settings,
it is better to configure Spread Spectrum(SS) at clock producer side,
I think.

Dario, 

Without talking about dt-bindings, another approach to enable SS
is to enable SS for Video/Audio PLLs using driver parameters,
and the parameter that needs for the PLLs could be passed
from module parameter, such as clk_imx8mm.audio_ss_xx=.

Then you no need bindings.

Regards,
Peng.

> 
> It's kind of similar for some OPP/performance/bandwidth requests.
> Even more similar to clock frequencies. Which device requests to
> configure given clock frequencies? Final consumer, not clock controller.
> 
> 
> >
> > For example, there are VPU_JPEG, VPU_DECODE, both will use video
> PLL
> > with high quality. So the clock producer just produce PLLs with
> Spread
> > Spectrum(SS) enabled, and put the SS properties under CCM or
> anatop
> > node, not video IP nodes.
> >
> >
> > We could have a talk on IRC if Dario, Abel and you are available to
> > discuss on this topic.
> 
> 
> 
> Best regards,
> Krzysztof