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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
