"Govindraj.R" <govindraj.r...@ti.com> writes:
> From: Kevin Hilman <khil...@ti.com>
>
> 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 <govindraj.r...@ti.com>
> Signed-off-by: Kevin Hilman <khil...@ti.com>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
