Hi Kevin,
On Friday 19 April 2013 08:22 PM, Kevin Hilman wrote:
Sourav Poddar<sourav.pod...@ti.com> writes:
[...]
Yes, got your point. omap_device_idle should not be called only
for console uart.
Just did a quick testing by including the following hunk on top of my
patch series..
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index c226946..7480e87 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -617,8 +617,10 @@ static int _od_suspend_noirq(struct device *dev)
ret = pm_generic_suspend_noirq(dev);
if (!ret&& !pm_runtime_status_suspended(dev)) {
- if (pm_generic_runtime_suspend(dev) == 0)
+ if (pm_generic_runtime_suspend(dev) == 0) {
+ omap_device_idle(pdev);
od->flags |= OMAP_DEVICE_SUSPENDED;
+ }
}
return ret;
@@ -631,6 +633,7 @@ static int _od_resume_noirq(struct device *dev)
if ((od->flags& OMAP_DEVICE_SUSPENDED)&&
!pm_runtime_status_suspended(dev)) {
+ omap_device_enable(pdev);
od->flags&= ~OMAP_DEVICE_SUSPENDED;
pm_generic_runtime_resume(dev);
}
And found the wakeup from UART is no more functional.
So, the omap_device_idle gets called for console UART also, thereby
preventing the "no_idle_on_suspend" theory.
Hence, merely putting prepare/complete callback the way I did is not
helping.
We need to delete omap_device_idle also, which I agree is not correct.
So, we need a way to bypass this "omap_device_idle"
call for console UART. ?
OK, I see what's happening now.
How about this: rather than using prepare/complete callbacks, can you
use the runtime_suspend callback to return an error code during suspend?
Yes, that can be done.
(only for the console, and only when no_console_suspend is enabled, and
only during suspend)
Since _od_suspend_noirq checks to be sure the drivers ->runtime_suspend
callback succeeds before it calls omap_device_idle(), if you report a
failure, omap_device_idle will not be called.
True.
~Sourav
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
