Re: (subset) [PATCH v12 00/19] Support spread spectrum clocking for i.MX8M PLLs

Dario Binacchi
2025-05-27T19:32:30Z

On Tue, May 27, 2025 at 8:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 23/05/2025 17:19, Dario Binacchi wrote:
> > Hello Abel,
> >
> > On Mon, May 5, 2025 at 9:52 AM Abel Vesa <abel.vesa@linaro.org> wrote:
> >>
> >>
> >> On Thu, 24 Apr 2025 08:21:30 +0200, Dario Binacchi wrote:
> >>> This version keeps the version v9 patches that can be merged and
> >>> removes the patches that will need to be modified in case Peng's
> >>> PR https://github.com/devicetree-org/dt-schema/pull/154 is accepted.
> >>> The idea is to speed up the merging of the patches in the series
> >>> that have already been reviewed and are not dependent on the
> >>> introduction of the assigned-clocks-sscs property, and postpone
> >>> the patches for spread spectrum to a future series once it becomes
> >>> clear what needs to be done.
> >>>
> >>> [...]
> >>
> >> Applied, thanks!
> >
> > I was surprised to see that the series has been removed from linux-next.
>
> Did you miss entire email thread explaining why? I think you never
> answered to several emails in this thread... and we - including myself -
> sent them a lot.

I don't think so:

The answers related to the errors encountered during DTC compilation:

https://lore.kernel.org/oe-kbuild-all/CABGWkvp7n=Or-OqnLoOJsQQCHF+=8eQ9EV5=O+Qp4sQF49_DbA@mail.gmail.com/
https://lore.kernel.org/all/CABGWkvqfyH=dcuw6EDZaFVVebj8SZhJF0P944+mmzL5YK3-Pug@mail.gmail.com/

The patch to fix the regression reported by Mark Brown:

https://lore.kernel.org/all/20250516134945.14692-1-dario.binacchi@amarulasolutions.com/

Also successfully tested by him.

And when I didn’t reply, I was expecting the maintainers to handle it
— as Peng Fan had requested in version 10:

https://lore.kernel.org/all/20250314093503.GD12210@nxa18884-linux/

I may have made some mistakes, but don't tell me I never replied.

After all, anyone can make mistakes:
https://lore.kernel.org/all/d421a6e8-e72c-48d9-8806-09724723b5d8@kernel.org/

Best regards,
Dario

>
> >
> > It’s been 8 months since the first version dated September 28, 2024.
> > The most critical phase was version 3 -
> > https://lore.kernel.org/all/20241106090549.3684963-1-dario.binacchi@amarulasolutions.com/
> > -
> > where two key issues emerged:
> >
> > 1 The CCM design is flawed because "in the current design, CCM is
> > taken as the producer of CLK_IMX8M_VIDEO_PLL, not the consumer."
> >
> > 2 A driver for anatop needs to be implemented because "using clocks
> > to replace fsl,ssc-clocks is possible under CCM mode, but you need
> > to develop the fsl,imx8mm-anatop clock driver."
> >
> > These development guidelines, agreed upon with Krzysztof and Peng,
> > enabled a coherent implementation of both the DT bindings and the
> > code. The following versions, from v4 to v8, were necessary to
> > review and refine those implementations, bringing us to January 2025.
> >
> > At that point, Peng opened a separate pull request -
> > https://github.com/devicetree-org/dt-schema/pull/154 -
> > for the definition of general-purpose DT bindings for spread spectrum
> > handling, which ended up invalidating mine.
> >
> > While waiting for his pull request to be accepted, I submitted version 9,
> > trying to at least get the patches for the anatop driver merged,
> > eventually reaching version 12.
> >
> > This final version was merged, but then a few days ago it was dropped.
>
> And explained why. There were bug reports which you completely ignored.
>
> >
> > As it stands now:
> >
> > - We still don’t have proper spread spectrum handling
> > - Peng’s pull request has been stalled since February 20
> > - We don’t have a driver for anatop
> > - The CCM design remains flawed
> > - Not even the first 4 patches of the series were merged — these were
> > simply a replication for i.MX8MM and i.MX8MP of patch
> > bedcf9d1dcf88 ("clk: imx: rename video\_pll1 to video\_pll"), which
> > was already merged some time ago.
> >
> > Could you please let me know if you're still interested in this series?
> > If so, could you suggest how to resolve the issues that led you to drop it?
>
>
> You got several replies what is wrong. Can you respond to these instead
> of coming now surprised?
>
> 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