[PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.

[b-cousson@ti.com (Cousson, Benoit)]

On 5/13/2011 3:16 PM, Hilman, Kevin wrote:
> Tony Lindgren<tony@atomide.com>  writes:
>
>> * Cousson, Benoit<b-cousson@ti.com>  [110513 15:18]:
>>>>>> Signed-off-by: Vladimir Zapolskiy<vzapolskiy@gmail.com>
>>>>>
>>>> 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