On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote: > * 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? One possibility is to pass to omap_serial_init() the omap_uart_config struct pointer to specify which parts are enabled. If a NULL is passed in, then enable all the ports available. Since omap_serial_early_init() was already called, the muxing would have to be cleaned up, but since the kernel should mux all the pins it uses, that shouldn't be a problem. omap_serial_init would now look something like(warning, coding on the fly - don't know if it will work as is): void __init omap_serial_init(struct omap_uart_config *confptr) { int i; for (i = 0; i < ARRAY_SIZE(omap_uart); i++) { struct omap_uart_state *uart = &omap_uart[i]; struct platform_device *pdev = &uart->pdev; struct device *dev = &pdev->dev; /* Only enable if (!confptr || confptr->port_enabled & (1<<i)) { omap_uart_reset(uart); omap_uart_idle_init(uart); if (WARN_ON(platform_device_register(pdev))) continue; if ((cpu_is_omap34xx() && uart->padconf) || (uart->wk_en && uart->wk_mask)) { device_init_wakeup(dev, true); DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout); } } } } > Regards, > > Tony -- Peter Barada <peterb@xxxxxxxxxxx> Logic Product Development, Inc. -- 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
