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

[Artem Bityutskiy <dedekind1@gmail.com>]

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.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html