Thread (2 messages) 2 messages, 2 authors, 2011-10-12
STALE5355d

[PATCH v6 14/16] OMAP2+: UART: Take console_lock in suspend path if not taken

From: Kevin Hilman <hidden>
Date: 2011-10-11 19:01:17
Also in: linux-omap, linux-serial

Possibly related (same subject, not in this thread)

"Govindraj.R" [off-list ref] writes:
In suspend path the console_lock is taken by uart_port_suspend
however when no_console_suspend is used console_lock is not taken.

During system wide suspend omap_pwr_domain hooks cut all
clocks that are left enabled. So its unsafe to proceed printing after
clocks are cut by pwr_domain hooks. 
As I've mentioned in previous reviews, when no_console_suspend is
enabled, the user has explicitly requested console output during
suspend.  In order to support that, we should not be cutting clocks at
all in that mode.

One way to address this would be to just disable runtime PM in the
->prepare method of the driver if no_console_suspend is enabled.
Also pm_runtime will be disabled after dpm_suspend devices happens.
Not sure why this is relevant.
So buffer all prints in suspend path by taking console_lock and print
them back safely after power domain hooks re-enable clocks back.

Use CONFIG_SERIAL_OMAP_CONSOLE macro check to take console_lock since
console ops are available only if omap console is defined.
omap-serial can be built as module without console support.
Please revisit use of #ifdefs.  (c.f. #ifdefs are ugly in
Documentation/SubmittingPatches)

Kevin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help