Re: Preventing OMAP3 serial driver to take control of all UARTs

[Tony Lindgren <tony@atomide.com>]

* Tony Lindgren <tony@atomide.com> [091130 11:40]:
> * Grant Likely <grant.likely@secretlab.ca> [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