Re: [PM-WIP-OPP][PATCH 3/4] omap: pm: opp: add ability to store data per opp

[Felipe Balbi <me@felipebalbi.com>]

Hi,

On Fri, Mar 19, 2010 at 10:25:18AM -0500, Nishanth Menon wrote:
> Now, based on your proposal as I understand,
> struct omap2_data {
> blah_o21
> blah_o22
> };
> 
> struct omap3_data {
> blah_o31
> blah_o32
> blah_o33
> }
> 
> struct omap4_data {
> blah_o41
> blah_o42
> blah_o31
> blah_o32
> }
> 
> and so on (remember we may have shared or similar data between various 
> SOCs at times)
> 
> redundancy, maintenance are the problems i see other than ability to 
> have a module which uses blah_o31 to be generic and not know the 
> difference between struct omap3_data and omap4_data
> the resultant module code will look like:
> if (cpu_is_omap3430()) {
> 	my_blaho31 = ((struct omap3_data *) get_opp_data(opp))->blah_o31;
> } else if cpu_is...() {
> ..
> }

ok, I get your point.

> now in the approach I took,
> you could have:
> struct sr_ntarget_type{
> 	unsigned long nTarget;
> 	something else if needed
> }
> 
> And in SR driver, the module doesnot need to care which silicon it is 
> running on.. it just does opp_get_data(opp,"sr_ntarget") and gets the 
> correct data for that silicon on that OPP. It is much simpler and 
> similar to the manner implemented in many other frameworks such as clock 
> etc..

the thing is that ideally it would simply:

opp_get_data(opp);

and that should be done so that it fits all possibilities, but if it's
that different per-SoC, then I guess there's nothing to do.

-- 
balbi