[PATCH RFC 0/3] clk: support arbitrary clk_register() sequence
Yang Xiwen
forbidden405 at outlook.com
Tue Oct 28 16:49:43 CET 2025
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
More information about the U-Boot
mailing list