Hi Kevin, On Friday 19 April 2013 08:22 PM, Kevin Hilman wrote:
Sourav Poddar<sourav.poddar@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
