lkml.org 
[lkml]   [2022]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH 0/7] clk: mediatek: Move to struct clk_hw provider APIs
From
Il 19/04/22 10:12, Chen-Yu Tsai ha scritto:
> Hi everyone,
>
> This is part 2 of my proposed MediaTek clk driver cleanup work [1].
>

..snip..

>
> The next phase of the cleanup/improvement shall be to introduce some
> variant of `struct clk_parent_data` to describe clk relationships
> efficiently.
>
> Please have a look.
>

Hello Chen-Yu,

I am grateful to see this series, as the MediaTek clock drivers are getting
a bit old, despite new platforms being implemented practically as we speak.

With this, you surely get that I completely agree with the proposed cleanup
and modernization of the entire MediaTek clocks infrastructure, but I think
that introducing a `struct clk_parent_data` for these drivers is, at this
point, a must, that not only fully justifies these patches, but also "makes
the point" - as the effect of that would be a performance improvement as we
would *at least* avoid lots of clk_cpy_name() in case of parent_hws, or in
case or parent_data where no .fw_name is provided (which would be the case
for most of the clocks).

That said, my advice would be to add that conversion to declaring clocks
with .hw.init.parent_data and/or .hw.init.parent_hws to this series as to
really make it complete.

Of course, if you have concerns about old platforms that you cannot test,
or for which this kind of conversion would require a huge amount of effort,
then I would go for converting as many as possible as a first step and then
leave the others for later.

I would envision MT8183, 8186, 8192, 8195 to be a good amount of first
candidates for this great effort.

Cheers,
Angelo

\
 
 \ /
  Last update: 2022-04-19 17:09    [W:0.131 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site