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

[Tony Lindgren <tony@atomide.com>]

* Artem Bityutskiy <dedekind1@gmail.com> [091203 00:46]:
> On Thu, 2009-12-03 at 08:56 +0200, Mika Westerberg wrote:
> > On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote:
> > > * Grant Likely <grant.likely@secretlab.ca> [091202 07:06]:
> > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > > * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> > > 
> > > <snip>
> > > 
> > > > >
> > > > > 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.
> > > 
> > > OK, sounds good to me.
> > 
> > Hi,
> > 
> > This device tree stuff sounds like very cool way of doing things. Hope
> > it is ready soon :)
> > 
> > Meanwhile, would it be OK to implement something to get the serial driver
> > taking control of the all the UARTs? Any comments on adding new function
> > to mach-omap2/serial.c: omap_serial_init_port(int port) that could be
> > used from board files instead of omap_serial_init()?
> 
> Device tree is really promising, but we do need an alternative method
> anyway, because not everyone will use the device tree. IOW, device tree
> does not exist yet, and will not be mandatory, so an alternative is
> required.

Right, it sounds like the device tree won't solve all the issues.

But before we change anything with the mach-omap2/serial.c, let's wait
until we hear comments from Kevin.

Regards,

Tony