* Artem Bityutskiy <[email protected]> [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 <[email protected]> [091202 07:06]: > > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <[email protected]> > > > > wrote: > > > > > * Grant Likely <[email protected]> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
