Re: [PATCH 2/9 v2] omap3: pm: introduce opp accessor functions

[Nishanth Menon <nm@ti.com>]

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