Romit Dasgupta wrote:
> 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.
What I meant to say is that CONFIG_PM & CONFIG_CPU_FREQ are independent. So this
is not correct.
--
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
