Subject: [PATCH 03/11] OMAP: UART: omap_device converions, remove implicit 8520 assumptions

From: [email-masked] (Kevin Hilman)
Date: Fri, 17 Sep 2010 16:43:23 -0700

"Govindraj.R" <[email-masked]> writes:

> From: Kevin Hilman <[email-masked]>
>
> Major rework of OMAP UART init for omap_device conversion as well as
> use with either 8250 driver or new omap-serial driver.
>
> In preparation for a new omap-serial driver, remove 8250 assumptions
> and dependencies from the serial core.
>
> Convert UART core and PM support to use omap_device layer. Also add
> support for both console on 8250 or omap-serial driver.
>
> omap_device conversion:
> - Convert clock API calls to omap_device calls
> - Remove all static platform_data setup and configuration.  This is
>   all done by the omap_device build phase.
>
> Signed-off-by: Govindraj.R <[email-masked]>
> Signed-off-by: Kevin Hilman <[email-masked]>
> ---
>  arch/arm/mach-omap2/serial.c |  528 +++++++++++++++++++++---------------------
>  1 files changed, 259 insertions(+), 269 deletions(-)
>

[...]

> +	/*
> +	 * Need to block sleep long enough for interrupt driven
> +	 * driver to start.  Console driver is in polling mode
> +	 * so device needs to be kept enabled while polling driver
> +	 * is in use.
> +	 */
> +	uart->timeout = (30 * HZ);

My fault, but there's a bug here.  This long timeout is only needed
when the init-time timout is non-zero, so should be:

	if (uart->timeout)
		uart->timeout = (30 * HZ);

Without this, even though the default timeout is zero (meaning, UARTs
should not timeout and go idle), a timer will fire 30 seconds after boot
and cause the UARTs to go idle.

I discovered this when seeing the UARTs go idle, even though the
timeouts were all set to zero.

Can you fold this into your the next version?

Thanks,

Kevin