Hi Yixun, On Sat, Oct 03, 2026 at 01:04:52AM +0000, Yixun Lan wrote: > .. this will enable parent, would be it ok to combine below > device_reparent() together? to simply use clk_set_parent(clk, > parent)? it make sense to me to reparent first then program > the divider
Yes, that is better. clk_set_parent() only enables the new parent when the clock itself is enabled, which also fixes the unbalanced clk_enable() in this version, and it matches Linux, where the core calls ccu_mux_set_parent() and then ccu_mix_set_rate(), each latched by its own frequency change. The one difference from this version is that, between the two frequency changes, the clock briefly runs from the new parent with the old divider. Linux has the same window, so I'll keep it simple unless you would rather have the divider written first whenever that window would exceed both the old and the new rate. v2 now reparents through clk_set_parent() first, then writes the divider and triggers the frequency change, and still writes nothing when the mux and divider already match. It also reparents when the hardware mux selects a different source even if the framework already has the chosen parent. The parent/divider selection algorithm is unchanged. I have retested the integrated board-support lane on next bd2f5794b7e2, with OpenSBI v1.9 and your FC fix from k3/for-next: - OrangePi R2S: eMMC SPL boot, SDH2 I/O clock 204.8 MHz, U-Boot HS200 at 200 MHz/8-bit, EFI and FreeBSD boot, and an unattended reboot. - OrangePi RV2: microSD SPL boot, U-Boot SD High Speed at 50 MHz, EFI and FreeBSD boot with root on NVMe; two boots checked. Both CPU clusters remain at 1600 MHz on both boards, and SSH works after boot. The R2S, RV2, generic K1 and RV2 SPI configurations build SPL and U-Boot proper without compiler warnings; the patch passes checkpatch. Generic K1 and RV2 SPI are build-only checks for this revision. I have not run before/after performance benchmarks. Thanks, Dave
