OMAP: misc. PM-related fixes for v3.1-rc

Hi Tony,

Here's my current collection of PM-related fixes for the -rc cycle.

They are based on the next/board branch of Arnd's arm-soc tree (which has already been merged by Linus) and are also available in the for_3.1/pm-fixes branch of my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

Kevin

Colin Cross (1):
OMAP2+: PM: SmartReflex: use put_sync_suspend for IRQ-safe disabling

Kevin Hilman (4):
OMAP2+: Kconfig: don't select PM in OMAP2PLUS_TYPICAL
OMAP1: enable GENERIC_IRQ_CHIP
OMAP3: beagle: don't touch omap_device internals
OMAP: McBSP: use existing macros for converting between devices

Nishanth Menon (1):
OMAP3+: SR: ensure pm-runtime callbacks can be invoked with IRQs
disabled

 arch/arm/mach-omap2/Kconfig             |    1 -
 arch/arm/mach-omap2/board-omap3beagle.c |   23 ++++++++++-------------
 arch/arm/mach-omap2/smartreflex.c       |    3 ++-
 arch/arm/plat-omap/Kconfig              |    1 +
 arch/arm/plat-omap/mcbsp.c              |    6 +++---
 5 files changed, 16 insertions(+), 18 deletions(-)

1.7.6

CONFIG_PM is no longer a user-selectable Kconfig option. Rather it is automatically enabled if either CONFIG_SUSPEND or CONFIG_RUNTIME_PM is enabled, so having a 'select PM' here is redunant when 'select CONFIG_PM_RUNTIME' is present.

---
 arch/arm/mach-omap2/Kconfig |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

index 4ae6257..57b66d5 100644
@@ -7,7 +7,6 @@ config ARCH_OMAP2PLUS_TYPICAL
 	default y
 	select AEABI
 	select REGULATOR
-	select PM
 	select PM_RUNTIME
 	select VFP
 	select NEON if ARCH_OMAP3 || ARCH_OMAP4

1.7.6

From: Nishanth Menon <[email protected]>

SmartReflex should be disabled while entering low power mode due to
a) SmartReflex values are not defined for retention voltage, further
b) with SmartReflex enabled, if CPU enters lower c-states, FSM will try to bump the voltage to current OPP's voltage for which it has entered c-state; hence SmartReflex needs to be disabled for MPU, CORE and IVA voltage domains in idle path before enabling auto retention voltage achievement on the device.

However, since the current pm_runtime setup for SmartReflex devices are setup to allow callbacks to be invoked with interrupts enabled, calling SmartReflex enable/disable from other contexts such as idle paths where preemption is disabled causes warnings such as the following indicating of a potential race.

[   82.023895] [<c04d079c>] (__irq_svc+0x3c/0x120) from [<c04d0484>] (_raw_spin_unlock_irq+0x28/0x2c)
[   82.023895] [<c04d0484>] (_raw_spin_unlock_irq+0x28/0x2c) from [<c0323234>] (rpm_callback+0x4c/0x68)
[   82.023956] [<c0323234>] (rpm_callback+0x4c/0x68) from [<c0323f7c>] (rpm_resume+0x338/0x53c)
[   82.023956] [<c0323f7c>] (rpm_resume+0x338/0x53c) from [<c03243f4>] (__pm_runtime_resume+0x48/0x60)
[   82.023986] [<c03243f4>] (__pm_runtime_resume+0x48/0x60) from [<c008aee0>] (sr_enable+0xa8/0x19c)
[   82.023986] [<c008aee0>] (sr_enable+0xa8/0x19c) from [<c008b2fc>] (omap_sr_enable+0x50/0x90)
[   82.024017] [<c008b2fc>] (omap_sr_enable+0x50/0x90) from [<c00888c0>] (omap4_enter_sleep+0x138/0x168)

Instead, we use pm_runtime_irq_safe to tell the PM core that callbacks can be invoked in interrupt disabled contexts.

---
 arch/arm/mach-omap2/smartreflex.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

index 2ce2fb7..dc8e86a 100644
@@ -860,6 +860,7 @@ static int __init omap_sr_probe(struct platform_device *pdev)
 	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 
 	pm_runtime_enable(&pdev->dev);
+	pm_runtime_irq_safe(&pdev->dev);
 
 	sr_info->pdev = pdev;
 	sr_info->srid = pdev->id;

1.7.6

OMAP1 needs this also since GPIO driver (common for all OMAPs) is being converted to use generic IRQ chip.

---
 arch/arm/plat-omap/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

index 49a4c75..9a4a6bf 100644
@@ -13,6 +13,7 @@ config ARCH_OMAP1
 	bool "TI OMAP1"
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
+	select GENERIC_IRQ_CHIP
 	help
 	  "Systems based on omap7xx, omap15xx or omap16xx"
 

1.7.6

Board code should not touch omap_device internals. To get the MPU/IVA devices, use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device().

---
 arch/arm/mach-omap2/board-omap3beagle.c |   23 ++++++++++-------------
 1 files changed, 10 insertions(+), 13 deletions(-)

index 32f5f89..3ae16b4 100644
@@ -491,23 +491,22 @@ static void __init beagle_opp_init(void)
 
 	/* Custom OPP enabled for all xM versions */
 	if (cpu_is_omap3630()) {
-		struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
-		struct omap_hwmod *dh = omap_hwmod_lookup("iva");
-		struct device *dev;
+		struct device *mpu_dev, *iva_dev;
 
-		if (!mh || !dh) {
+		mpu_dev = omap2_get_mpuss_device();
+		iva_dev = omap2_get_iva_device();
+
+		if (!mpu_dev || !iva_dev) {
 			pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
-				__func__, mh, dh);
+				__func__, mpu_dev, iva_dev);
 			return;
 		}
 		/* Enable MPU 1GHz and lower opps */
-		dev = &mh->od->pdev.dev;
-		r = opp_enable(dev, 800000000);
+		r = opp_enable(mpu_dev, 800000000);
 		/* TODO: MPU 1GHz needs SR and ABB */
 
 		/* Enable IVA 800MHz and lower opps */
-		dev = &dh->od->pdev.dev;
-		r |= opp_enable(dev, 660000000);
+		r |= opp_enable(iva_dev, 660000000);
 		/* TODO: DSP 800MHz needs SR and ABB */
 		if (r) {
 			pr_err("%s: failed to enable higher opp %d\n",

@@ -516,10 +515,8 @@ static void __init beagle_opp_init(void)
 			 * Cleanup - disable the higher freqs - we dont care
 			 * about the results
 			 */
-			dev = &mh->od->pdev.dev;
-			opp_disable(dev, 800000000);
-			dev = &dh->od->pdev.dev;
-			opp_disable(dev, 660000000);
+			opp_disable(mpu_dev, 800000000);
+			opp_disable(iva_dev, 660000000);
 		}
 	}
 	return;

1.7.6

From: Colin Cross <[email protected]>

omap_sr_disable_reset_volt is called with irqs off in omapx_enter_sleep, as part of idle sequence, this eventually calls sr_disable and pm_runtime_put_sync. pm_runtime_put_sync calls rpm_idle, which will enable interrupts in order to call the callback. In this short interval when interrupts are enabled, scenarios such as the following can occur:
while interrupts are enabled, the timer interrupt that is supposed to wake the device out of idle occurs and is acked, so when the CPU finally goes to off, the timer is already gone, missing a wakeup event.

Further, as the documentation for runtime states:"
However, subsystems can use the pm_runtime_irq_safe() helper function to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume() callbacks should be invoked in atomic context with interrupts disabled (->runtime_idle() is still invoked the default way)."

Hence, replace pm_runtime_put_sync with pm_runtime_put_sync_suspend to invoke the suspend handler and shut off the fclk for SmartReflex module instead of using the idle handler in interrupt disabled context.

---
 arch/arm/mach-omap2/smartreflex.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index dc8e86a..34c01a7 100644
@@ -621,7 +621,7 @@ void sr_disable(struct voltagedomain *voltdm)
 			sr_v2_disable(sr);
 	}
 
-	pm_runtime_put_sync(&sr->pdev->dev);
+	pm_runtime_put_sync_suspend(&sr->pdev->dev);
 }
 
 /**

1.7.6

For converting from struct device to platform_device, and from platform_device to struct omap_device, there are existing macros. Use them instead of manual use of container_of().

---
 arch/arm/plat-omap/mcbsp.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

index 3c1fbdc..47016f7 100644
@@ -260,9 +260,9 @@ EXPORT_SYMBOL(omap_mcbsp_dma_reg_params);
 #ifdef CONFIG_ARCH_OMAP3
 static struct omap_device *find_omap_device_by_dev(struct device *dev)
 {
-	struct platform_device *pdev = container_of(dev,
-					struct platform_device, dev);
-	return container_of(pdev, struct omap_device, pdev);
+	struct platform_device *pdev = to_platform_device(dev);
+
+	return to_omap_device(pdev);
 }
 
 static void omap_st_on(struct omap_mcbsp *mcbsp)

1.7.6

Hi Kevin

Jarkko

Indeed, that's a much better alternative. I didn't bother to check if th resulting omap_device pointer was actually used.

Yeah, yours is a better patch and we should take that one. Feel free to add

I'll include it in my series for reference also (because I need it due to modifying how platform_device is contained within an omap_device) but yours will probably make it upstream first since I'm about to go offline for ~2 weeks.

Thanks,

Kevin

Thanks, based on your comment looks like you want to modify at least one of them. I'll pick the ones that should get merged immediately while you're on vacation.

Regards,

Tony

Hmm as it looks like you already dropped the last patch, I'll pull the first five into fixes.

Tony