[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs

[nm@ti.com (Nishanth Menon)]

Roger Quadros had written, on 09/16/2010 09:20 AM, the following:
[...]
>>>> +/**
>>>> + * opp_get_freq() - Gets the frequency corresponding to an opp
>>>> + * @opp:       opp for which frequency has to be returned for
>>>> + *
>>>> + * Return frequency in hertz corresponding to the opp, else
>>>> + * return 0
>>>> + */
>>>> +unsigned long opp_get_freq(const struct omap_opp *opp)
>>>> +{
>>>> +       if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
>>> ditto.
>> Yes, the intent here was for opp operational apis to function ONLY on
>> the enabled opps - this helps to pull out any bugs in the users
>> who might be unintentionally using bad params.
>>
> OK.
> 
>> do you have any usecase you can think of where we might want to use
>> these on a disabled opp?
> 
> Not really. Based on what is an OPP enabled/disabled? Is it possible for 
> an initially enabled OPP to be disabled at some point in time? What 
> triggers this disable?
> OR  does an OPP enabled at boot time remain enabled throughout the power 
> session?
At this point - enable/disable is done at init time - there is 
flexibility for board files to define their own custom OPPs (as some 
custom boards need to). they dont change once this initial definition is 
done. there are plans to do dynamic enable disable based on previous 
discussion in l-o - the framework to use opp layer in that manner is yet 
to go up yet.

-- 
Regards,
Nishanth Menon