aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm
diff options
context:
space:
mode:
authorPaul Walmsley <paul@pwsan.com>2012-03-03 15:15:33 -0500
committerKevin Hilman <khilman@ti.com>2012-03-05 18:38:02 -0500
commitb7c39a3f59ae55aa49ebf670e9329bc7da6d3c65 (patch)
treeea8d0eaec71e624250288371bd11df30cceb858c /arch/arm
parent3ec2decbb6dfcdbbb6e6a8ddf5adc7edbc429ed7 (diff)
ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set
During system suspend, when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set on an omap_device, call the corresponding driver's ->suspend() and ->suspend_noirq() callbacks (if present). Similarly, during resume, the driver's ->resume() and ->resume_noirq() callbacks must both be called, if present. (The previous code only called ->suspend_noirq() and ->resume_noirq().) If all of these callbacks aren't called, some important driver suspend/resume code may not get executed. In current mainline, the bug fixed by this patch is only a problem under the following conditions: - the kernel is running on an OMAP4 - an OMAP UART is used as a console - the kernel command line parameter 'no_console_suspend' is specified - and the system enters suspend ("echo mem > /sys/power/state"). Under this combined circumstance, the system cannot be awakened via the serial port after commit be4b0281956c5cae4f63f31f11d07625a6988766c ("tty: serial: OMAP: block idle while the UART is transferring data in PIO mode"). This is because the OMAP UART driver's ->suspend() callback is never called. The ->suspend() callback would have called uart_suspend_port() which in turn would call enable_irq_wake(). Since enable_irq_wake() isn't called for the UART's IRQ, check_wakeup_irqs() would mask off the UART IRQ in the GIC. On v3.3 kernels prior to the above commit, serial resume from suspend presumably occurred via the PRCM interrupt. The UART was in smart-idle mode, so it was able to send a PRCM wakeup which in turn would be converted into a PRCM interrupt to the GIC, waking up the kernel. But after the above commit, when the system is suspended in the middle of a UART transmit, the UART IP block would be in no-idle mode. In no-idle mode, the UART won't generate wakeups to the PRCM when incoming characters are received; only GIC interrupts. But since the UART driver's ->suspend() callback is never called, uart_suspend_port() and enable_irq_wake() is never called; so the UART interrupt is masked by check_wakeup_irqs() and the UART can't wake up the MPU. The remaining mechanism that could have awakened the system would have been I/O chain wakeups. These wouldn't be active because the console UART's clocks are never disabled when no_console_suspend is used, preventing the full chip from idling. Also, current mainline doesn't yet support full chip idle states for OMAP4, so I/O chain wakeups are not enabled. This patch is the result of a collaboration. John Stultz <johnstul@us.ibm.com> and Andy Green <andy.green@linaro.org> reported the serial wakeup problem that led to the discovery of this problem. Kevin Hilman <khilman@ti.com> narrowed the problem down to the use of no_console_suspend. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: John Stultz <johnstul@us.ibm.com> Cc: Andy Green <andy.green@linaro.org> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
Diffstat (limited to 'arch/arm')
-rw-r--r--arch/arm/plat-omap/omap_device.c12
1 files changed, 4 insertions, 8 deletions
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 1ae9d6f653a9..6de28ea3cd65 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -754,14 +754,12 @@ static int _od_suspend_noirq(struct device *dev)
754 struct omap_device *od = to_omap_device(pdev); 754 struct omap_device *od = to_omap_device(pdev);
755 int ret; 755 int ret;
756 756
757 if (od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND)
758 return pm_generic_suspend_noirq(dev);
759
760 ret = pm_generic_suspend_noirq(dev); 757 ret = pm_generic_suspend_noirq(dev);
761 758
762 if (!ret && !pm_runtime_status_suspended(dev)) { 759 if (!ret && !pm_runtime_status_suspended(dev)) {
763 if (pm_generic_runtime_suspend(dev) == 0) { 760 if (pm_generic_runtime_suspend(dev) == 0) {
764 omap_device_idle(pdev); 761 if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
762 omap_device_idle(pdev);
765 od->flags |= OMAP_DEVICE_SUSPENDED; 763 od->flags |= OMAP_DEVICE_SUSPENDED;
766 } 764 }
767 } 765 }
@@ -774,13 +772,11 @@ static int _od_resume_noirq(struct device *dev)
774 struct platform_device *pdev = to_platform_device(dev); 772 struct platform_device *pdev = to_platform_device(dev);
775 struct omap_device *od = to_omap_device(pdev); 773 struct omap_device *od = to_omap_device(pdev);
776 774
777 if (od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND)
778 return pm_generic_resume_noirq(dev);
779
780 if ((od->flags & OMAP_DEVICE_SUSPENDED) && 775 if ((od->flags & OMAP_DEVICE_SUSPENDED) &&
781 !pm_runtime_status_suspended(dev)) { 776 !pm_runtime_status_suspended(dev)) {
782 od->flags &= ~OMAP_DEVICE_SUSPENDED; 777 od->flags &= ~OMAP_DEVICE_SUSPENDED;
783 omap_device_enable(pdev); 778 if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
779 omap_device_enable(pdev);
784 pm_generic_runtime_resume(dev); 780 pm_generic_runtime_resume(dev);
785 } 781 }
786 782