* Re: Linus being annoyed by the ARM kernel code
[not found] ` <4D99875C.8060004-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
@ 2011-04-04 11:29 ` jonsmirl-Re5JQEeQqe8AvxtiuMwx3w
0 siblings, 0 replies; only message in thread
From: jonsmirl-Re5JQEeQqe8AvxtiuMwx3w @ 2011-04-04 11:29 UTC (permalink / raw)
To: andy.green-QSEj5FYQhm4dnm+yROfE0A, Grant Likely,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: Andy Green, Nicolas Pitre, Linaro Dev, Eric Miao
On Mon, Apr 4, 2011 at 4:54 AM, Andy Green <andy-/Zus8d0mwwtBDgjK7y7TUQ@public.gmane.org> 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.
--
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
^ permalink raw reply [flat|nested] only message in thread