Dear Aneesh V,
In message 4DD27893.5000606@ti.com you wrote:
It appears this might be part of or taken from some bigger scope clocks framework. Otherwise it's diffcult for me to understand why OMAP4 needs 1400+ lines of code, when other SoCs appear to do with considerably less. Please comment.
No. This code was written for SPL. Please note that a lot of it is tables used for PLL locking, clock enabling etc. OMAP4 supports different crystal frequencies. So, more entries in each table. Also, there are some special handling based on the OMAP4 revisions because of some frequency limitations. So, more number of tables.
hm... is this really a type of selection that has to be done at runtime? In the real system, the frequencies will probably pretty much fixed, and not dynamically adjusted in U-Boot. So maybe we can compile at least poarts of this at build time?
NAK. We do not accept base address plus offset notation. Please declare C structs instead.
Ok. will do.
Again just curious, what's the reasoning behind this policy? Is it just aesthetics or something more?
It's more. When using base+offset, the compiler will know nothing about the data type, so it canot warn you if you use a 32 bit accessor on a 8 bit register, or vice versa. When you pass a struct element, it can check type information.
Best regards,
Wolfgang Denk