On Sun, Apr 3, 2011 at 12:46 PM, Matt Sealey <m...@genesi-usa.com> wrote:
> At the point where device tree specification and maintenance is done
> in-kernel, device trees get very Linux-specific and very
> Linux-driver-specific. Plenty of mistakes were made in the move to
> flattened device trees on PowerPC which took too long to resolve.

This another good point. If you find yourself sticking Linux specific
information (like module names) into the device tree, then something
is wrong in the kernel, go fix the kernel. The device tree should only
contain a generic description of the hardware that can be used by any
operating system.

On the other hand, device trees aren't a static solution. For example,
they haven't come up with a generic mechanism for completely
describing things like clock and power management domains. But let's
figure out schemes for describing these problem areas and fix the
device tree model.  As more architectures utilize device trees these
problem areas should get figured out and the issues will go away. So
if you find yourself adding thousands of lines of board specific code
to the kernel, something is probably wrong in the device tree generic
hardware description, go fix it.

This is an evolutionary process. Start off with selecting in-kernel
device trees based on machine ID. Start off with describing the basic
hardware in the device tree and remove the old kernel code that was
building the description. Move on to device trees provided by the
bootloader. After basic hardware description is converted move on to
more complex areas like clock and power domains.

A big effect of switching to device trees is to make kernel developers
stop and think about generic solutions to problems instead of adding
another 1,000 lines of one-off code to the kernel. The quicker ARM
converts to device trees the easier the task will be.

-- 
Jon Smirl
jonsm...@gmail.com

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to