[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABGWkvpu+quSY1y7u7eXOuiDLz8j2Sgs=sn=muZW80e-vNnHbg@mail.gmail.com>
Date: Tue, 27 May 2025 21:32:18 +0200
From: Dario Binacchi <dario.binacchi@...rulasolutions.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Abel Vesa <abel.vesa@...aro.org>, linux-kernel@...r.kernel.org,
Peng Fan <peng.fan@....com>, Stephen Boyd <sboyd@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
linux-amarula@...rulasolutions.com, Abel Vesa <abelvesa@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Fabio Estevam <festevam@...il.com>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Michael Turquette <mturquette@...libre.com>,
Pengutronix Kernel Team <kernel@...gutronix.de>, Rob Herring <robh@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>, devicetree@...r.kernel.org, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
Subject: Re: (subset) [PATCH v12 00/19] Support spread spectrum clocking for
i.MX8M PLLs
On Tue, May 27, 2025 at 8:42 PM Krzysztof Kozlowski <krzk@...nel.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@...aro.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@...rulasolutions.com
__________________________________
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
info@...rulasolutions.com
www.amarulasolutions.com
Powered by blists - more mailing lists