[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Nishanth Menon
nm at ti.com
Thu Sep 16 10:43:01 EDT 2010
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
More information about the linux-arm-kernel
mailing list