Re: [PATCH v4 7/8] clk: sunxi-ng: a733: Add bus clock gates

["Junhui Liu" <junhui.liu@pigmoral.tech>]

Hi Enzo,
Thanks for the feedback.

On Sat Sep 26, 2026 at 10:03 AM CST, Enzo Adriano wrote:
> Hi Junhui,
>
> Thanks for reproducing the ahb-cpus issue. Adding clk_ignore_unused lets
> the Cubie A7S reach an interactive initramfs shell.
>
> I reused the September 21 uninstrumented comparator: v7.3-rc1 plus the
> four single-divider patches, CCU v4, the seven pinctrl patches, and the
> minimal test DT, with only ahb_cpus_clk marked CLK_IS_CRITICAL. The Image,
> DTB and initramfs were byte-identical to that earlier comparator; the
> only boot-argument change was adding clk_ignore_unused.

I tried to reproduce your software stack: v7.3-rc1 plus the four
single-divider patches, CCU v4 with ahb_cpus_clk marked CLK_IS_CRITICAL,
the seven pinctrl patches, and a minimal test DT based on my
understanding of your description. On my Cubie A7A, it completes
clk_disable_unused() and reaches PID 1 without clk_ignore_unused, so I
still cannot reproduce the second failure.

>
> Without the flag, that comparator stopped producing serial output at
> "clk: Disabling unused clocks". With it, the confirmation run recorded:
>
>   [    1.263452] clk: Not disabling unused clocks
>   [    1.292364] Run /bin/sh as init process
>   [    1.526500] mmc0: new high speed SDXC card at address 544c
>
> Commands issued after the shell prompt returned the expected readiness
> and completion markers. No panic, oops or SError appeared in the capture.
> The RAM-only run was followed by a guarded 120-second power-off recovery,
> which restored the vendor kernel and eMMC root.
>
> This narrows the second failure to the path bypassed by clk_ignore_unused,
> but does not identify an individual clock: the flag also bypasses the
> runtime-PM acquisition and traversal before the per-clock disable calls.
> I therefore still cannot add a Tested-by for v4 as posted.

Could you share the exact minimal DT used for the test, either by email
or through a git branch I can access?

Could you also provide some details about the boot firmware you used,
including where the U-Boot and TF-A images came from and their versions?
I would like to reproduce the test with the same firmware and rule out
differences in the boot firmware.

>
> Assisted-by: Codex:gpt-6
>
> Regards,
> Enzo

-- 
Best regards,
Junhui Liu