On 10/15/2025 6:03 AM, Tom Rini wrote:
On Sat, Jun 21, 2025 at 06:54:17PM +0800, Yang Xiwen wrote:
Currently U-Boot clk framework mandates the sequence of registering clks
to begin from root, and then its children. This is an addtional
requirement that doesn't exist in Linux kernel, which makes clk driver
porting more difficult.
Let's handle this entirely in clk framework and give driver the freedom
to register clocks in any order.
This is done by assigning the parent "lazily". It will cache the parent
name in the core clk struct and try to refresh it when clk consumers
call clk_get_parent(). It's transparent to clk consumers as long as they
only use APIs provided by clk framework.
I've ran `ut dm clk*` and verified these commits does not break any
existing testcases. Though no new testcase is added because I think
existing testcases already test the logic very well.
Sorry for the very late review. When I build this on say
rock-4c-plus-rk3399 this is the size growth I see:
rock-4c-plus-rk3399: all +228 spl/u-boot-spl:all +500
spl/u-boot-spl:text +500 text +228 tpl/u-boot-tpl:all +552 tpl/u-boot-tpl:text
+552
u-boot: add: 1/0, grow: 1/0 bytes: 228/0 (228)
function old new delta
device_reparent - 120 +120
clk_get_parent 56 164 +108
spl-u-boot-spl: add: 4/0, grow: 1/0 bytes: 500/0 (500)
function old new delta
uclass_find_device_by_namelen - 172 +172
device_reparent - 120 +120
clk_get_parent 56 144 +88
uclass_find_device_by_name - 68 +68
uclass_get_device_by_name - 52 +52
tpl-u-boot-tpl: add: 5/0, grow: 1/0 bytes: 552/0 (552)
function old new delta
uclass_find_device_by_namelen - 172 +172
device_reparent - 120 +120
clk_get_parent 56 144 +88
uclass_find_device_by_name - 68 +68
uclass_get_device_by_name - 52 +52
strncmp - 52 +52
(using buildman's 'bloat' features to report size change). I'm fine with
the growth in U-Boot itself, but that's just too much in SPL and TPL and
we need to figure out if we can avoid that somehow.
I'll make this feature optional for SPL/TPL, but would still like it to
be always enabled for U-Boot itself.
--
Regards,
Yang Xiwen
