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.