Thread (22 messages) 22 messages, 2 authors, 2012-11-08
STALE4948d

[PATCH 12/13] ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call

From: paul@pwsan.com (Paul Walmsley)
Date: 2012-10-25 23:21:22
Also in: linux-omap
Subsystem: arm port, omap hwmod support, omap2+ support, the rest · Maintainers: Russell King, Paul Walmsley, Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren, Linus Torvalds

The hwmod code unconditionally calls _omap4_disable_module() on all
SoCs when a module doesn't enable correctly.  This "worked" due to the
weak function omap4_cminst_wait_module_idle() in
arch/arm/mach-omap2/prcm.c, which was a no-op.  But now those weak
functions are going away - they should not be used.  So this patch
will now call the SoC-specific disable_module code, assuming it
exists.

Needs to be done before the weak function is removed, otherwise AM33xx
will crash early in boot.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bc891e9..85e8874 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2062,7 +2062,8 @@ static int _enable(struct omap_hwmod *oh)
 			_enable_sysc(oh);
 		}
 	} else {
-		_omap4_disable_module(oh);
+		if (soc_ops.disable_module)
+			soc_ops.disable_module(oh);
 		_disable_clocks(oh);
 		pr_debug("omap_hwmod: %s: _wait_target_ready: %d\n",
 			 oh->name, r);
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help