On Mon, Apr 4, 2011 at 4:54 AM, Andy Green andy@warmcat.com wrote:
Another way to solve it, would be to encode the set of device trees supported in a way that removes redundancy. Then the additional data needed to resolve a generic OMAP3 device table into overo or beagle or any similar board would be a small increment. The encoded table can be initdata and gotten rid of after being rendered into the DT required.
Grant, this is an interesting idea...
Suppose Linux develops a standardized DT format for describing things like clock and power domains. This domain data is then acted on by generic code in the kernel. The domain data is CPU specific, not board specific.
It would make sense to me to not put this data into the board specific device trees. Board specific device trees include the CPU identifier. During the Linux boot process we could look at the CPU identifier and then expand the in-memory DT with CPU specific info like the clock and power domains.
Since each CPU variant would expand into the corresponding nodes we can now write generic code that acts on this data in a manner that is not bound to the specific CPU. Keeping data like this out of the board specific DT makes them easier to write. There's nothing to be gained by adding dozens of CPU specific nodes to a board level device tree.