ARM: OMAP2+: UART: Do not gate uart clocks if used for debug_prints
authorGovindraj.R <govindraj.raja@ti.com>
Wed, 21 Sep 2011 11:24:12 +0000 (16:54 +0530)
committerKevin Hilman <khilman@ti.com>
Thu, 15 Dec 2011 00:05:26 +0000 (16:05 -0800)
commit36fc2d15b120ef85be74c68b5ad74ac04fbefa8a
tree208dfab0524b24860414c6368c8544e6050b4dfa
parent08f86b3eab9807e6d36de7e00025abad893ff557
ARM: OMAP2+: UART: Do not gate uart clocks if used for debug_prints

If OMAP UART is used as console uart and debug is enabled,
avoid gating of uart clocks to print all debug prints.

If uart clocks are gated then the debug prints from omap_device
framework or hwmod framework can cause uart to enter recursive
pm_runtime calls, which can cause a deadlock over power lock usage.

For example: Say, uart clocks are cut and we get a print from
omap_device_disable stating disabling uart clocks. This print
calls omap_uart driver console_write which will call runtime API
get_sync which means we enter from runtime API put context to
runtime API get context.

--> runtime put (take power lock)
    --> print disabling uart clocks
        --> call uart console write
            --> call get_sync (try to take power lock)

Also any clock enable API call from uart driver should not call any uart
operation until clocks are enabled back. Like get_sync having debug print
calling uart console write even before clocks are enabled.

So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used
in debug mode. If so, do not set device_may_wakeup. This will prevent
pm_runtime_enable in uart driver and will avoid uart clock gating.
Debug is enabled either by adding debug word in bootarg or by setting
loglevel=10

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
arch/arm/mach-omap2/serial.c