aboutsummaryrefslogtreecommitdiff
path: root/Documentation/sparse.txt
diff options
context:
space:
mode:
authorGovindraj.R <govindraj.raja@ti.com>2011-09-21 16:54:12 +0530
committerKevin Hilman <khilman@ti.com>2011-12-14 16:05:26 -0800
commit36fc2d15b120ef85be74c68b5ad74ac04fbefa8a (patch)
tree208dfab0524b24860414c6368c8544e6050b4dfa /Documentation/sparse.txt
parent08f86b3eab9807e6d36de7e00025abad893ff557 (diff)
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>
Diffstat (limited to 'Documentation/sparse.txt')
0 files changed, 0 insertions, 0 deletions