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
--
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
