* Grant Likely <grant.likely@xxxxxxxxxxxx> [091130 09:01]: > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada <peterb@xxxxxxxxxxx> wrote: > > On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote: > >> Hi Tony, > >> > >> Current omap serial driver takes control of all 3 (4 on OMAP3640) > >> UARTS. However, we have such a setup where UART2 for example is used > >> by bluetooth driver. It uses the UART as non-standard way (there are > >> some Nokia extensions to H4 protocol) so we cannot use the standard > >> driver for driving the UART but have written special one for that > >> purpose. > >> > >> Question is: Is there any, upstreamable, way of preventing omap serial > >> driver to do this? Currently this is done with custom #ifdef hackery to > >> mach-omap2/serial.c. Alternative solution that comes into mind is to > >> specify UART configuration in board files and let serial driver to use > >> that instead of hard-coded one. Or do you have some nice alternatives? > > > > Previously (back around 2.6.28-rc8) in the board file, the > > omap_uart_config struct controlled which serial ports were enabled on > > startup. It was used in omap_serial_init, and it looks like that code > > went away with the following commit: > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c > > > > I'm kinda in the same boat as I want to use some of the unused serial > > port pins for GPIO, but they are setup as serial ports.... Sounds like we need something back to specify the ports to use from board-*.c files. Kevin, got any comments? > 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? Regards, Tony -- 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
