>>> 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
As I mentioned there is a __fundamental__ problem in OMAP3 PM tree today.
CONFIG_CPU_FREQ, CONFIG_CPU_IDLE are made dependent on CONFIG_PM. You can have
cpufreq, cpuidle without suspend resume. So IMHO making these features
independent is the right fix.
--
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
