On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Grant Likely <grant.likely@xxxxxxxxxxxx> [091130 09:01]: >> http://www.elinux.org/Device_Trees >> >> I expect to have my prototype ready for review mid-January, and most >> of the common code should be either merged or queued up in linux-next >> by that time. > > While device tree is a nice solution to some of the problems, it still > leaves all the issues we already have with buggy and and outdated > bootloaders. So we still need to properly initialize the devices in > the kernel. Yes, buggy firmware is still a problem. However, if the required configuration is described in the device tree data, then for some things the driver can handle setting up the device and the amount of board-specific code can be reduced. > Just for reference, most of the omap bootloader bugs seem to be > related to not muxing the pins right or using wrong timings for GPMC. > > And then things that mostly change during the board development are > the GPIO pins, but those can be easily rewritten in the board-*.c > files based on the omap_rev. > > But at least the device tree is a standard model, while the earlier > omap tag approach was non-standard. > > Peter, maybe you've already thought through all this.. But would it be > possible to do lightweight device tree that we just use to populate > the platform data? This is completely possible. Just having the device tree available doesn't force the kernel to use it for everything. I've found it useful to start small and add things as I need them. Most important thing to remember is to follow the documented & established device tree conventions so that common code can understand it. Oh, and speaking of GPIOs, there is a binding for describing GPIO pin connections in the device tree: Documentation/powerpc/dts-bindings/gpio/gpio.txt Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
