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