Hi Chuan Liu,

On Mon, Feb 9, 2026 at 6:49 AM Chuan Liu via B4 Relay
[off-list ref] 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.


Best regards,
Martin


[0] https://lore.kernel.org/linux-amlogic/1j1pnp5sg7.fsf@starbuckisacylon.baylibre.com/ (local)
[1] https://lore.kernel.org/linux-amlogic/1639bb9d-9cb7-409f-bbf8-bfe4a5d1b8bc@amlogic.com/ (local)