Dasgupta, Romit had written, on 01/15/2010 07:23 AM, the following:
Nishanth Menon wrote:
omap3_pm_init_opp_table should be under #ifdef CONFIG_PM
else build fails when PM is disabled. Reported by Paul originally.
Cc: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>
Cc: Paul Walmsley <paul@xxxxxxxxx>
Reported-by: Paul Walmsley <paul@xxxxxxxxx>
Signed-off-by: Nishanth Menon <nm@xxxxxx>
---
arch/arm/mach-omap2/pm.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index d257225..5fc056f 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -69,7 +69,13 @@ static inline void omap3_pm_init_vc(struct prm_setup_vc *setup_vc)
* Initialize the basic opp table here, board files could choose to modify opp
* table after the basic initialization
*/
+#ifdef CONFIG_PM
extern void omap3_pm_init_opp_table(void);
+#else
+static inline void omap3_pm_init_opp_table(void)
+{
+}
+#endif
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
This patch IMHO just solves the build issue. The runtime behaviour is a nasty
crash. OMAP architecture has tied CONFIG_PM with CONFIG_CPU_FREQ. So I think we
need a fix that solves the runtime behavior too.
hmm.. thanks for pointing it out (dropping the patch) - even though that
was not the reason for this patch - I had send this patch after booting
the kernel using omap3_pm_defconfig (disable PM) on SDP3630:
SDP3630: http://pastebin.mozilla.org/697292 - complete boot
SDP3430: http://pastebin.mozilla.org/697294 - hang
--
Regards,
Nishanth Menon
--
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
