Menon, Nishanth had written, on 11/15/2009 08:54 AM, the following:
[...]
b) Improvements of the omap accessor functions, I will send out few of
the proposals I can think of later when I get some free time.. we can
discuss that too.
Here is my initial proposal, do feel free to comment/add/modify etc:
In the accessor functions listed here, I have followed:
a) The function will return 0 if success else appropriate error values,
all values are passed by pointer params.
b) Overall, the idea is to transition from exposing omap_opp to users
currently to a system where opp handling logic will be blackboxed from
the rest of the system - giving us options to optimize and scale
internal logic and storage mechanism without impacting the rest of the
system.
c) resultant code should be readable - this is one of the issues I see
with my previous implementation.
Files: Introduce opp.c and opp.h
A) Data Structures:
Interim:
opp.h
struct omap_opp {
bool enabled;
unsigned long rate; /* in hz */
u8 opp_id; /* int */
u16 vsel; /* T2 voltage value */
};
typedef struct omap_opp omap_opp_def;
Final, once resource34xx.c and all direct accesses are cleaned up:
opp.h:
struct omap_opp;
/* initial definitions of OPP, will be used by all */
struct omap_opp_def {
bool enabled; /* true/false */
unsigned long rate; /* in hz */
u16 vsel; /* in millivolts */
};
opp.c:
struct omap_opp {
bool enabled;
unsigned long rate;
u16 vsel;
};
or what ever implementation it needs. can be array, list, hash
implementation or what ever we choose it to be.
B) Accessor functions to be used:
B.1) These functions should be removed once SRF is replaced/cleaned up:
int opp_id_to_freq(unsigned long *freq, const struct omap_opp *opps, u8
opp_id);
int opp_freq_to_id(u8 *opp_id, const struct omap_opp *opps, unsigned
long freq);
B.2) initialization functions:
/* Register the OPP list for the silicon */
int opp_register(struct omap_opp *opp_list,
const struct omap_opp_def *opp_reg);
/* Enable a specific frequency */
int opp_enable(struct omap_opp *opp_list,
unsigned long freq, bool enable);
Users:
opp_register will be called by pm34xx.c based on silicon type.
opp_enable will be called by board file/ has_feature based logic etc..
on a need basis
B.3) verification functions:
/* Check if we have a frequency in the list(enabled/disabled)
* this is needed by users who would like to enable a disabled
* frequency
*/
int opp_has_freq(struct omap_opp *opp_list, unsigned long freq);
/* Check if we have a enabled frequency - this is what most users
* will need
*/
int opp_is_freq_valid(struct omap_opp *opp_list, unsigned long freq);
Users:
files who'd want to use opp_enable,
validation paths.
B.4) Limit functions:
/* To get a number of frequencies enabled */
int opp_get_freq_count(const struct omap_opp *opp_list, u8 *num);
/* Get highest enabled frequency */
int opp_get_highest_freq(struct omap_opp *opp_list,
unsigned long *freq);
/* Get lowest enabled frequency */
int opp_get_lowest_freq(struct omap_opp *opp_list, unsigned long *freq);
Users:
Obvious user is the current cpufreq
B.5) Search functions -> these will check only enabled frequencies. This
will not check if the start freq provided in *freq is an enabled
frequency or not. Assumption I am making is: if you are searching for a
frequency that is disabled in the opp list, you are not trying something
generic -hence wont support.
/* Get higher enabled frequency than the provided one */
int opp_get_higher_freq(struct omap_opp *opp_list, unsigned long *freq);
/* Get lower enabled frequency than the provided one */
int opp_get_lower_freq(struct omap_opp *opp_list, unsigned long *freq);
Users:
current srf, future scale logic
B.6) voltage functions - opp layer will not trigger voltage transition,
it is upto other users of opp layer to make a decision.
/* get voltage corresponding to a frequency */
int opp_freq_to_voltage(u16 *voltage, struct omap_opp *opp_list,
unsigned long *freq);
Users:
current SR/SRF, future voltage framework.
--
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
