On 04/22/2013 04:43 PM, Sourav Poddar wrote:
The driver manages "no_console_suspend" by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Signed-off-by: Sourav Poddar <sourav.pod...@ti.com>
---
drivers/tty/serial/omap-serial.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 08332f3..640b14e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1582,7 +1582,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
struct uart_omap_port *up = dev_get_drvdata(dev);
struct omap_uart_port_info *pdata = dev->platform_data;
- if (!up)
+ if (!up || (!console_suspend_enabled && uart_console(&up->port)))
return -EINVAL;
Hi Sourav,
No ) You will block Runtime PM for console UART forever, but instead
it need to be blocked only during suspend - autosuspend should continue
working.
But this will be not easy, again, -
because System suspend isn't synchronized with Runtime PM (I mean,
serial_omap_suspend/resume() may be called from one thread and
serial_omap_runtime_suspend/resume() from another at same time).
And now, serial_omap_suspend() callback is the only one place where you
can detect that system is going to sleep.
Personally, i don't believe in such approach (my experiences from K3.4
said me
that there will be more problems than benefits).
And, I like combination of "no_console_suspend" in bootargs +
"ti,no_idle_on_suspend" for console UART in DT, because 1) it's debug
option and 2) until
smth. will be decided about OMAP OCP Bus it can be used.
It's just my opinion.
Regards,
-grygorii
if (!pdata)
@@ -1614,6 +1614,9 @@ static int serial_omap_runtime_resume(struct device *dev)
int loss_cnt = serial_omap_get_context_loss_count(up);
+ if (!console_suspend_enabled && uart_console(&up->port))
+ return -EINVAL;
+
if (loss_cnt < 0) {
dev_err(dev, "serial_omap_get_context_loss_count failed : %d\n",
loss_cnt);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
