lkml.org 
[lkml]   [2012]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 3/4] clk: introduce the common clock framework
On Fri, Mar 16, 2012 at 08:23:57PM -0700, Saravana Kannan wrote:
...
> Hi Mike,
>
> I already took a quick look at the v7 series, but I thought this
> thread has more relevant context for my response. So, responding
> here.
>
> I'm with Sascha on creating a clk_internal/clk_initializer and
> removing clk_hw. You had asked about the benefits of his suggestion
> in one of the earlier threads. I'm sure I have told some of these
> reasons I don't like clk_hw, but repeating my points here for others
> to chime in.
>
> I used to be a huge proponent for using macros for clocks in our
> internal tree. All the clocks were constructed using macros (you
> will see it in the history of tree we publish in CAF). They quickly
> became unreadable when you have several hundreds of clocks. The
> biggest problem is that you can't quickly look at a clock's macro
> and figure out what the register offset or bit mask or shift value
> is. Our eyes/brains aren't meant for quickly parsing the commas and
> finding the n-th field or even remembering what the n-th field of
> each macro corresponds to. If it's actually broken out as fields in
> a struct, it's much easier to read. So, long story short, I think
> the well-intentioned helper macros will make code quite unreadable.
>
While I second the idea of clk_initializer, using macros is not really
the thing to complain. You can save using those macro helpers by
calling APIs clk_register_*(). But that does not solve the problem,
because those APIs also have a long argument list to fill.

--
Regards,
Shawn


\
 
 \ /
  Last update: 2012-03-19 06:41    [W:0.375 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site