On 5/13/2011 3:16 PM, Hilman, Kevin wrote:
Tony Lindgren<tony@xxxxxxxxxxx> writes:
* Cousson, Benoit<b-cousson@xxxxxx> [110513 15:18]:
Signed-off-by: Vladimir Zapolskiy<vzapolskiy@xxxxxxxxx>
Unfortunately I don't have an automated tool, but that would be great
to have such a script. For this time I've checked the correctness of the
change comparing the preprocessed output.
In fact these files are already generated automatically, as written
in the header file. So changing the output format should
straightforward. At least for OMAP4... OMAP2 and OMAP3 were done
manually some time ago.
Sounds like the important thing to consider here is how these macros
should be set up considering the upcoming generic clock framework
and device tree changes.
So let's wait a few days for comments from Benoit and Paul on the
format for the macros so we don't need to redo them again later.
Of course there might be other things to consider too..
... like readability.
After seeing the patch (thanks Benoit), I think this is bad tradeoff
between readability and lines-of-code.
Personally, I don't think we should be trading readability for diffstat
goodness. I have a strong dislike for these multi-line macros, but
it's up to Paul/Benoit to decide how this should look.
I'm sharing the same concern and after seeing the patch, I do thing as
well that the readability is badly impacted.
My other concern is that these macros are too low level and does not
bring a real abstraction of clock nodes.
Any change to the clock structure we will have to do in the near future
with the common clock fmwk will probably have an impact on this file.
So if we want to reduce the file size using that kind of approach, we'd
better provide improved macros that will help hiding some implementation
details. It will ease the transition to the common clock fmwk.
Last but not least, since we do want to move this file to DT ASAP, is it
worth it?
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
