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

[Peter Barada <peterb@logicpd.com>]

On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote:
> * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada <peterb@logicpd.com> 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@logicpd.com>
Logic Product Development, Inc.