Menon, Nishanth wrote: > Romit Dasgupta had written, on 01/19/2010 08:09 AM, the following: >>>>> >>>> Err... NAK.. I think you missed >>>> http://marc.info/?t=126356119700001&r=1&w=2 ? >>>> there seems to be an issue else where, I have not dug at it yet.. >>> Yeah. OK, I couldn't see the logs as the dumps has been removed already >>> from that thread. >>> But if I got the problem correctly, the problem is when CONFIG_PM is not >>> set but cpu freq is. >>> And if there is any call to new omap opp layer helper functions, then it >>> will BUG the system. >>> Causing hangs. >>> >>> I guess one way to solve this is to bind compilation of omap opp layer to >>> CONFIG_PM and CONFIG_CPU_FREQ. >>> If either is disabled, then omap opp layer must be nops. >>> >>> What do you think? >>> >>> I am sending a patch to do the above. >> No. That is incorrect. CONFIG_CPU_FREQ, CONFIG_CPU_IDLE and CONFIG_PM are >> independent. None of the features should be dependent on the other two! >> -Romit > OPP layer is required by CPU_FREQ & CONFIG_PM, not CPU_IDLE. > > if we modify Eduardo's patch from: > > if defined(CONFIG_PM) && defined(CONFIG_CPU_FREQ) > To > > if defined(CONFIG_PM) || defined(CONFIG_CPU_FREQ) > > wont that ensure the independence is maintained for OPP layer? then, > probably pm34xx.c maynot be the right place for opp registration for > 3430 opps, and we should move it to opp34xx.c(I hate having new files :( ).. > It should be only #ifdef CONFIG_CPU_FREQ. OPP has nothing to do with CONFIG_PM.
Why do you need CPU_FREQ for suspend/resume?? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
