ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc

Hi,

Here is an initial set of fixes for power management and OMAP core infrastructure for 3.5-rc. Most of these patches address boot warnings and power management problems on OMAP4, although a few of them address more general issues.

Thanks to (in alphabetical order) Beno?t Cousson, Tero Kristo, Kevin Hilman, Vaibhav Hiremath, and Tony Lindgren for help with this series.

Compile- and boot-test information is below. Note that on OMAP3, return from suspend when off-mode is enabled is via GPIO buttons due to:

http://www.spinics.net/lists/arm-kernel/msg173688.html

Boot logs are available from:

http://www.pwsan.com/omap/bootlogs/20120617/omap_fixes_a_3.5rc__52a5ae406dadef781bfcf3a641dae2064e9697ff/

These patches are available via git from git://git.pwsan.com/linux-2.6
in the branch 'omap_fixes_a_3.5rc'.

This third version adds a fix for a new sparse warning, and drops everything that is still being commented on or reviewed or which needs acks. Hopefully those will make it into a future 3.5-rc series.

- Paul

---

object size (delta in bytes from v3.5-rc3 (485802a6c524e62b5924849dd727ddbb1497cc71)):
text data bss total kernel

    0 	    0 	    0 	    0 	5912osk_testconfig/vmlinux
  +32 	    0 	    0 	  +32 	n800_multi_omap2xxx/vmlinux
  +64 	    0 	    0 	  +64 	n800_testconfig/vmlinux
    0 	    0 	    0 	    0 	omap1510_defconfig/vmlinux
    0 	    0 	    0 	    0 	omap1_defconfig/vmlinux
  +64 	    0 	    0 	  +64 	omap2_4_testconfig/vmlinux
+4160 	    0 	    0 	+4160 	omap2plus_defconfig/vmlinux
    0 	    0 	    0 	    0 	omap2plus_no_pm/vmlinux
    0 	    0 	    0 	    0 	omap3_4_testconfig/vmlinux
    0 	    0 	    0 	    0 	omap3_testconfig/vmlinux
  +64 	    0 	    0 	  +64 	omap4_testconfig/vmlinux

Djamil Elaidi (1):
ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby

Paul Walmsley (5):
ARM: OMAP2+: hwmod code/data: fix 32K sync timer
ARM: OMAP4: hwmod data: fix 32k sync timer idle modes
ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks
ARM: OMAP2+: CM: increase the module disable timeout
ARM: OMAP2+: mux: fix sparse warning

Todd Poynor (1):
ARM: OMAP: PM: Lock clocks list while generating summary

 arch/arm/mach-omap2/clock44xx_data.c         |    5 +++++
 arch/arm/mach-omap2/cm.h                     |   11 ++++++++++
 arch/arm/mach-omap2/cminst44xx.c             |    4 ++--
 arch/arm/mach-omap2/mux.c                    |    1 +
 arch/arm/mach-omap2/omap_hwmod.c             |   28 ++++++++++++++++++--------
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c   |    2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   |    6 +++---
 arch/arm/plat-omap/clock.c                   |    2 ++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    9 ++++++++
 9 files changed, 53 insertions(+), 15 deletions(-)

From: Todd Poynor <[email protected]>

Commit a53025724052b2b1edbc982a4a248784638f563d (OMAP: Add debugfs node to show the summary of all clocks) introduced clock summary, however, we are interested in seeing snapshot of the clock state, not in dynamically changing clock configurations as the data provided by clock summary will then be useless for debugging configuration issues. So, hold the common lock when dumping the clock summary.

---
 arch/arm/plat-omap/clock.c |    2 ++
 1 file changed, 2 insertions(+)

index 62ec5c4..706b7e2 100644
@@ -461,6 +461,7 @@ static int clk_dbg_show_summary(struct seq_file *s, void *unused)
 	struct clk *c;
 	struct clk *pa;
 
+	mutex_lock(&clocks_mutex);
 	seq_printf(s, "%-30s %-30s %-10s %s\n",
 		"clock-name", "parent-name", "rate", "use-count");
 

@@ -469,6 +470,7 @@ static int clk_dbg_show_summary(struct seq_file *s, void *unused)
 		seq_printf(s, "%-30s %-30s %-10lu %d\n",
 			c->name, pa ? pa->name : "none", c->rate, c->usecount);
 	}
+	mutex_unlock(&clocks_mutex);
 
 	return 0;
 }

Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c ("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database") broke CORE idle on OMAP3. This prevents device low power states.

The root cause is that the 32K sync timer IP block does not support smart-idle mode[1], and so the hwmod code keeps the IP block in no-idle mode while it is active. This in turn prevents the WKUP clockdomain from transitioning to idle. There is a hardcoded sleep dependency that prevents the CORE_L3 and CORE_CM clockdomains from transitioning to idle when the WKUP clockdomain is active[2], so the chip cannot enter any device low power states.

It turns out that there is no need to take the 32k sync timer out of idle. The IP block itself probably does not have any native idle handling at all, due to its simplicity. Furthermore, the PRCM will never request target idle for this IP block while the kernel is running, due to the sleep dependency that prevents the WKUP clockdomain from idling while the CORE_L3 clockdomain is active. So we can safely leave the 32k sync timer in target-force-idle mode, even while we continue to access it.

This workaround is implemented by defining a new hwmod flag, HWMOD_ALWAYS_FORCE_SIDLE, that places the IP block into target force-idle mode even when enabled. The 32k sync timer hwmods are marked with this flag for OMAP3 and OMAP4 SoCs. (On OMAP2xxx, no OCP header existed on the 32k sync timer.)

Another theoretically clean fix for this problem would be to implement PM runtime-based control for 32k sync timer accesses. These PM runtime calls would need to located in a custom clocksource, since the 32k sync timer is currently used as an MMIO clocksource. But in practice, there would be little benefit to doing so; and there would be some cost, due to the addition of unnecessary lines of code and the additional CPU overhead of the PM runtime and hwmod code - unnecessary in this case.

Another possible fix would have been to modify the pm34xx.c code to force the IP block idle before entering WFI. But this would not have been an acceptable approach: we are trying to remove this type of centralized IP block idle control from the PM code.

This patch is effectively a workaround for a hardware problem. A better hardware approach would have been to implement a smart-idle target idle mode for this IP block. The smart-idle mode in this case would behave identically to the force-idle mode. We consider the force-idle and no-idle target idle mode settings to be intended for debugging and automatic idle management bug workarounds only[4].

This patch is a collaboration between Kevin Hilman <[email protected]> and Paul Walmsley <[email protected]>.

Thanks to Vaibhav Hiremath <[email protected]> for providing comments on an earlier version of this patch. Thanks to Tero Kristo <[email protected]> for identifying a bug in an earlier version of this patch. Thanks to Beno?t Cousson <[email protected]> for identifying some bugs in an earlier version of this patch and for implementation comments.

References:

1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU (SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip

2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU (SWPU223U)

3. ibid.

4. Section 3.1.1.1.2 "Module-Level Clock Management" of the OMAP4430 TRM Rev. vAA (SWPU231AA).

---
 arch/arm/mach-omap2/omap_hwmod.c             |   26 ++++++++++++++++++--------
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c   |    2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   |    2 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    9 +++++++++
 4 files changed, 29 insertions(+), 10 deletions(-)

index bf86f7e..e174c2a 100644
@@ -1124,10 +1124,12 @@ static struct omap_hwmod_addr_space * __init _find_mpu_rt_addr_space(struct omap
  * _enable_sysc - try to bring a module out of idle via OCP_SYSCONFIG
  * @oh: struct omap_hwmod *
  *
- * If module is marked as SWSUP_SIDLE, force the module out of slave
- * idle; otherwise, configure it for smart-idle.  If module is marked
- * as SWSUP_MSUSPEND, force the module out of master standby;
- * otherwise, configure it for smart-standby.  No return value.
+ * Ensure that the OCP_SYSCONFIG register for the IP block represented
+ * by @oh is set to indicate to the PRCM that the IP block is active.
+ * Usually this means placing the module into smart-idle mode and
+ * smart-standby, but if there is a bug in the automatic idle handling
+ * for the IP block, it may need to be placed into the force-idle or
+ * no-idle variants of these modes.  No return value.
  */
 static void _enable_sysc(struct omap_hwmod *oh)
 {

@@ -1141,8 +1143,11 @@ static void _enable_sysc(struct omap_hwmod *oh)
 	sf = oh->class->sysc->sysc_flags;
 
 	if (sf & SYSC_HAS_SIDLEMODE) {
-		idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
-			HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+		if (oh->flags & HWMOD_ALWAYS_FORCE_SIDLE)
+			idlemode = HWMOD_IDLEMODE_FORCE;
+		else
+			idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
+				HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
 		_set_slave_idlemode(oh, idlemode, &v);
 	}
 

@@ -1208,8 +1213,13 @@ static void _idle_sysc(struct omap_hwmod *oh)
 	sf = oh->class->sysc->sysc_flags;
 
 	if (sf & SYSC_HAS_SIDLEMODE) {
-		idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
-			HWMOD_IDLEMODE_FORCE : HWMOD_IDLEMODE_SMART;
+		/* XXX What about HWMOD_IDLEMODE_SMART_WKUP? */
+		if (oh->flags & HWMOD_SWSUP_SIDLE ||
+		    !(oh->class->sysc->idlemodes &
+		      (SIDLE_SMART | SIDLE_SMART_WKUP)))
+			idlemode = HWMOD_IDLEMODE_FORCE;
+		else
+			idlemode = HWMOD_IDLEMODE_SMART;
 		_set_slave_idlemode(oh, idlemode, &v);
 	}
 

index b26d3c9..f8ac9e7 100644
@@ -2018,7 +2018,7 @@ static struct omap_hwmod omap3xxx_counter_32k_hwmod = {
 	.name		= "counter_32k",
 	.class		= &omap3xxx_counter_hwmod_class,
 	.clkdm_name	= "wkup_clkdm",
-	.flags		= HWMOD_SWSUP_SIDLE,
+	.flags		= HWMOD_ALWAYS_FORCE_SIDLE | HWMOD_SWSUP_SIDLE,
 	.main_clk	= "wkup_32k_fck",
 	.prcm		= {
 		.omap2	= {

index 950454a..4aaaa84 100644
@@ -408,7 +408,7 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
 	.name		= "counter_32k",
 	.class		= &omap44xx_counter_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.flags		= HWMOD_SWSUP_SIDLE,
+	.flags		= HWMOD_ALWAYS_FORCE_SIDLE | HWMOD_SWSUP_SIDLE,
 	.main_clk	= "sys_32k_ck",
 	.prcm = {
 		.omap4 = {

index c835b71..038c0d7 100644
@@ -409,6 +409,14 @@ struct omap_hwmod_omap4_prcm {
  *     in order to complete the reset. Optional clocks will be disabled
  *     again after the reset.
  * HWMOD_16BIT_REG: Module has 16bit registers
+ * HWMOD_ALWAYS_FORCE_SIDLE: Always program this module's SIDLEMODE to
+ *     force-idle mode, even when enabled.  This is needed for IP blocks
+ *     which do not support smart idle, which do not have a software
+ *     controllable functional or interface clock, and which the PRCM
+ *     will not assert SIdleReq until the kernel is not currently
+ *     running on the chip (e.g., the MPU is in idle).  For such modules,
+ *     fine-grained PM runtime-based idle control is simply a waste of
+ *     CPU cycles.
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)

@@ -419,6 +427,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_NO_IDLEST				(1 << 6)
 #define HWMOD_CONTROL_OPT_CLKS_IN_RESET		(1 << 7)
 #define HWMOD_16BIT_REG				(1 << 8)
+#define HWMOD_ALWAYS_FORCE_SIDLE		(1 << 9)
 
 /*
  * omap_hwmod._int_flags definitions

From: Djamil Elaidi <[email protected]>

If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.

---
 arch/arm/mach-omap2/omap_hwmod.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index e174c2a..a6da0b3 100644
@@ -530,7 +530,7 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
 	if (oh->class->sysc->idlemodes & SIDLE_SMART_WKUP)
 		_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART, v);
 	if (oh->class->sysc->idlemodes & MSTANDBY_SMART_WKUP)
-		_set_master_standbymode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
+		_set_master_standbymode(oh, HWMOD_IDLEMODE_SMART, v);
 
 	/* XXX test pwrdm_get_wken for this hwmod's subsystem */
 

The 32k sync timer IP block target idle modes in the hwmod data are incorrect. The IP block does not support any smart-idle modes. Update the data to reflect the correct modes.

This problem was initially identified and a diff fragment posted to the lists by Beno?t Cousson <[email protected]>. A patch description bug in the first version was also identified by Beno?t.

---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

index 4aaaa84..6b0aedc 100644
@@ -393,8 +393,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_counter_sysc = {
 	.rev_offs	= 0x0000,
 	.sysc_offs	= 0x0004,
 	.sysc_flags	= SYSC_HAS_SIDLEMODE,
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
-			   SIDLE_SMART_WKUP),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO),
 	.sysc_fields	= &omap_hwmod_sysc_type1,
 };
 

Until the OMAP4 code is converted to disable the use of the clock framework-based clockdomain enable/disable sequence, any clock used as a hwmod main_clk must have a clockdomain associated with it. This patch populates some clock structure clockdomain names to resolve the following warnings during kernel init:

omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.

---
 arch/arm/mach-omap2/clock44xx_data.c |    5 +++++
 1 file changed, 5 insertions(+)

index 2172f66..e2b701e 100644
@@ -84,6 +84,7 @@ static struct clk slimbus_clk = {
 
 static struct clk sys_32k_ck = {
 	.name		= "sys_32k_ck",
+	.clkdm_name	= "prm_clkdm",
 	.rate		= 32768,
 	.ops		= &clkops_null,
 };

@@ -512,6 +513,7 @@ static struct clk ddrphy_ck = {
 	.name		= "ddrphy_ck",
 	.parent		= &dpll_core_m2_ck,
 	.ops		= &clkops_null,
+	.clkdm_name	= "l3_emif_clkdm",
 	.fixed_div	= 2,
 	.recalc		= &omap_fixed_divisor_recalc,
 };

@@ -769,6 +771,7 @@ static const struct clksel dpll_mpu_m2_div[] = {
 static struct clk dpll_mpu_m2_ck = {
 	.name		= "dpll_mpu_m2_ck",
 	.parent		= &dpll_mpu_ck,
+	.clkdm_name	= "cm_clkdm",
 	.clksel		= dpll_mpu_m2_div,
 	.clksel_reg	= OMAP4430_CM_DIV_M2_DPLL_MPU,
 	.clksel_mask	= OMAP4430_DPLL_CLKOUT_DIV_MASK,

@@ -1149,6 +1152,7 @@ static const struct clksel l3_div_div[] = {
 static struct clk l3_div_ck = {
 	.name		= "l3_div_ck",
 	.parent		= &div_core_ck,
+	.clkdm_name	= "cm_clkdm",
 	.clksel		= l3_div_div,
 	.clksel_reg	= OMAP4430_CM_CLKSEL_CORE,
 	.clksel_mask	= OMAP4430_CLKSEL_L3_MASK,

@@ -2824,6 +2828,7 @@ static const struct clksel trace_clk_div_div[] = {
 static struct clk trace_clk_div_ck = {
 	.name		= "trace_clk_div_ck",
 	.parent		= &pmd_trace_clk_mux_ck,
+	.clkdm_name	= "emu_sys_clkdm",
 	.clksel		= trace_clk_div_div,
 	.clksel_reg	= OMAP4430_CM_EMU_DEBUGSS_CLKCTRL,
 	.clksel_mask	= OMAP4430_CLKSEL_PMD_TRACE_CLK_MASK,

Hi Paul,

From: Benoit Cousson <[email protected]>
Date: Fri, 15 Jun 2012 11:26:49 +0200
Subject: [PATCH] ARM: OMAP2+: hwmod: Do not check clkdm for main_clk if oh does have one

When a clkdm is handled directly at the hwmod level, there is no need to handle
it with the main_clk as well. It is thus useless to complain about the missing clkdm for the main_clk in that case.

Warn only if the clkdm is missing in both main_clk and hwmod.

Init hwmod clkdm first to ensure it will be there when the main_clk will be initialized.

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

index 162f9c7..f33f4e2 100644
@@ -609,7 +609,7 @@ static int _init_main_clk(struct omap_hwmod *oh)
 		return -EINVAL;
 	}
 
-	if (!oh->_clk->clkdm)
+	if (!oh->_clk->clkdm && !oh->clkdm)
 		pr_warning("omap_hwmod: %s: missing clockdomain for %s.\n",
 			   oh->main_clk, oh->_clk->name);
 

@@ -1339,10 +1339,10 @@ static int _init_clocks(struct omap_hwmod *oh, void *data)
 
 	pr_debug("omap_hwmod: %s: looking up clocks\n", oh->name);
 
+	ret |= _init_clkdm(oh);
 	ret |= _init_main_clk(oh);
 	ret |= _init_interface_clks(oh);
 	ret |= _init_opt_clks(oh);
-	ret |= _init_clkdm(oh);
 
 	if (!ret)
 		oh->_state = _HWMOD_STATE_CLKS_INITED;

1.7.0.4

Hi

Well as mentioned already on the lists, these clockdomains clearly exist; they are documented in the TRM and functional specification, and make sense from a chip perspective.

For 3.6, I've already agreed to remove those clockdomains, even though it doesn't really match what's there on the chip. But I think 3.6 is the right time to do that.

Please document what systems this has been tested on.

- Paul

Hi Paul,

OK, let's clarify: These are not clock domains for PRCM standpoint. These are the clock generators inside the PRCM, but they do not follow the functional clock domain mechanism at all.

Because of that they do not have any regular clkdm registers and that's why it does not worth using the current clkdm infrastructure since there is no SW control for them.

What is missing to make these domains valid is to extend the current definition to handle both the clock consumer domains and the clock generators.

OK, fair enough. I'll base the further cleanup series on that one.

For the moment, Thunderbird 13.0.1 only since I do not have any board accessible :-(.

Regards,
Benoit

Increase the timeout for disabling an IP block to five milliseconds. This is to handle the usb_host_fs idle latency, which takes almost four milliseconds after a host controller reset.

This is the second of two patches needed to resolve the following boot warning:

omap_hwmod: usb_host_fs: _wait_target_disable failed

---
 arch/arm/mach-omap2/cm.h                   |   11 +++++++++++
 arch/arm/mach-omap2/cminst44xx.c           |    4 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 3 files changed, 14 insertions(+), 2 deletions(-)

index a7bc096..f24e3f7 100644
@@ -22,4 +22,15 @@
  */
 #define MAX_MODULE_READY_TIME		2000
 
+/*
+ * MAX_MODULE_DISABLE_TIME: max duration in microseconds to wait for
+ * the PRCM to request that a module enter the inactive state in the
+ * case of OMAP2 & 3.  In the case of OMAP4 this is the max duration
+ * in microseconds for the module to reach the inactive state from
+ * a functional state.
+ * XXX FSUSB on OMAP4430 takes ~4ms to idle after reset during
+ * kernel init.
+ */
+#define MAX_MODULE_DISABLE_TIME		5000
+
 #endif

index 8c86d29..1a39945 100644
@@ -313,9 +313,9 @@ int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_off
 
 	omap_test_timeout((_clkctrl_idlest(part, inst, cdoffs, clkctrl_offs) ==
 			   CLKCTRL_IDLEST_DISABLED),
-			  MAX_MODULE_READY_TIME, i);
+			  MAX_MODULE_DISABLE_TIME, i);
 
-	return (i < MAX_MODULE_READY_TIME) ? 0 : -EBUSY;
+	return (i < MAX_MODULE_DISABLE_TIME) ? 0 : -EBUSY;
 }
 
 /**

index 6b0aedc..a428305 100644
@@ -30,6 +30,7 @@
 #include <plat/mmc.h>
 #include <plat/dmtimer.h>
 #include <plat/common.h>
+#include <plat/usb.h>
 
 #include "omap_hwmod_common_data.h"
 

Hello.

[...]

Hello Sergei,

Indeed, it's not. Thanks for pointing this out. Updated patch below.

- Paul

From: Paul Walmsley <[email protected]>
Date: Sun, 17 Jun 2012 11:57:53 -0600
Subject: [PATCH] ARM: OMAP2+: CM: increase the module disable timeout

Increase the timeout for disabling an IP block to five milliseconds. This is to handle the usb_host_fs idle latency, which takes almost four milliseconds after a host controller reset.

This is the second of two patches needed to resolve the following boot warning:

omap_hwmod: usb_host_fs: _wait_target_disable failed

Thanks to Sergei Shtylyov <[email protected]> for finding an unrelated hunk in a previous version of this patch.

---
 arch/arm/mach-omap2/cm.h         |   11 +++++++++++
 arch/arm/mach-omap2/cminst44xx.c |    4 ++--
 2 files changed, 13 insertions(+), 2 deletions(-)

index a7bc096..f24e3f7 100644
@@ -22,4 +22,15 @@
  */
 #define MAX_MODULE_READY_TIME		2000
 
+/*
+ * MAX_MODULE_DISABLE_TIME: max duration in microseconds to wait for
+ * the PRCM to request that a module enter the inactive state in the
+ * case of OMAP2 & 3.  In the case of OMAP4 this is the max duration
+ * in microseconds for the module to reach the inactive state from
+ * a functional state.
+ * XXX FSUSB on OMAP4430 takes ~4ms to idle after reset during
+ * kernel init.
+ */
+#define MAX_MODULE_DISABLE_TIME		5000
+
 #endif

index 8c86d29..1a39945 100644
@@ -313,9 +313,9 @@ int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_off
 
 	omap_test_timeout((_clkctrl_idlest(part, inst, cdoffs, clkctrl_offs) ==
 			   CLKCTRL_IDLEST_DISABLED),
-			  MAX_MODULE_READY_TIME, i);
+			  MAX_MODULE_DISABLE_TIME, i);
 
-	return (i < MAX_MODULE_READY_TIME) ? 0 : -EBUSY;
+	return (i < MAX_MODULE_DISABLE_TIME) ? 0 : -EBUSY;
 }
 
 /**

1.7.10

Commit bbd707acee279a61177a604822db92e8164d00db ("ARM: omap2: use machine specific hook for late init") resulted in the addition of this sparse warning:

arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static?

Fix by including the header file containing the prototype.

---
 arch/arm/mach-omap2/mux.c |    1 +
 1 file changed, 1 insertion(+)

index 80e55c5..d3ef99c 100644
@@ -41,6 +41,7 @@
 #include "control.h"
 #include "mux.h"
 #include "prm.h"
+#include "common.h"
 
 #define OMAP_MUX_BASE_OFFSET		0x30	/* Offset from CTRL_BASE */
 #define OMAP_MUX_BASE_SZ		0x5ca