On Thu, Dec 03, 2009 at 11:52:44AM -0800, Tony Lindgren wrote: > * Artem Bityutskiy <dedekind1@xxxxxxxxx> [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@xxxxxxxxxxxx> [091202 07:06]: > > > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > > > * Grant Likely <grant.likely@xxxxxxxxxxxx> [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. Tony, Kevin, Any comments on this? Thanks, MW -- 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
