Re: [PATCH 06/13] clk: amlogic: Add noglitch clock driver

From: Chuan Liu <chuan.liu@amlogic.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/13] clk: amlogic: Add noglitch clock driver
Date: Wed, 8 Apr 2026 22:44:54 +0800	[thread overview]
Message-ID: <40e2f836-4a6a-485a-9b92-1e42dc606e0f@amlogic.com> (raw)
In-Reply-To: <CAFBinCBXFxefUkNj3sqUdnTz7vf72jV_FkCP6gd2veTtLHWnBg@mail.gmail.com>

Hi Martin,
Thanks for review.

On 2/10/2026 5:51 AM, Martin Blumenstingl wrote:
> [ EXTERNAL EMAIL ]
> 
> Hi Chuan Liu,
> 
> On Mon, Feb 9, 2026 at 6:49 AM Chuan Liu via B4 Relay
> <devnull+chuan.liu.amlogic.com@kernel.org> wrote:
> [...]
>> + * To prevent glitches from propagating to clk_out and affecting the normal
>> + * operation of glitch-sensitive modules, the no-glitch clock must be configured
>> + * following the specified sequence:
>> + *   - When the clock gate is disabled: configure it as a normal composite clock
>> + *     (any glitches generated will be blocked by the gate and will not
>> + *     propagate to clk_out).
> This part is easy and makes sense.
> 
>> + *   - When the clock gate is enabled: configure it according to the following
>> + *     sequence to suppress glitches:
>> + *       - Configure and enable the idle composite clock path of the
>> + *         noglitch_mux with the target frequency/parent clock.
>> + *       - Switch the noglitch_mux to the channel prepared in the previous step.
>> + *       - Disable the clock of the original noglitch_mux channel.
>> + */
>  From a previous discussion it seems that in reality things need to be
> handled more carefully as you previously mentioned that
> CLK_SET_RATE_GATE is not good enough (the description above is what
> CLK_SET_RATE_GATE already achieves).
> For the more careful handling Jerome suggested using the clock
> protection logic: [0]
> You wanted to try it out at some point: [1]
> Is the verdict that Jerome's suggestion did not work? Can you please
> share some details as to why it doesn't work.
> 

In the actual use case, this switching operation completes within the 
nanosecond range (with a minimum clock frequency of 24 MHz in typical 
scenarios), which is why no issues were observed on our previous SoCs.

Thank you for the reminder, to be on the safe side, I will introduce 
some explicit hardware delays in the future revision.

> 
> Best regards,
> Martin
> 
> 
> [0] https://lore.kernel.org/linux-amlogic/1j1pnp5sg7.fsf@starbuckisacylon.baylibre.com/
> [1] https://lore.kernel.org/linux-amlogic/1639bb9d-9cb7-409f-bbf8-bfe4a5d1b8bc@amlogic.com/

-- 
Best regards,
Chuan

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic