* Tony Lindgren <tony@xxxxxxxxxxx> [091130 11:40]: > * Grant Likely <grant.likely@xxxxxxxxxxxx> [091130 09:01]: > > > Not in mainlined yet, but I'm working on porting flattened device tree > > support to OMAP to solve exactly this sort of problem. Basically, > > instead of hard coding or #ifdeffing things, a data blob gets handed > > to the kernel at boot time telling it exactly what hardware is present > > in a consistent, parsable format. Device drivers then get probed > > based on data in the device tree. Here's some info on the approach: > > > > 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. > > 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? Sorry, I meant to ask Grant this question as Grant (and not Peter) is working on the device tree. Tony -- 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
